Co obejmuje umowa serwisowa aplikacji, a za co zapłacisz osobno?

Tekst wygenerowany przez AI · Wydawca: Tomasz Niedźwiecki · zawiera oznaczoną reklamę jego usług

Co powinien obejmować abonament utrzymaniowy?

Abonament obejmuje wszystko, co jest potrzebne, żeby gotowa aplikacja działała tak samo jak w dniu odbioru. Należą do niego serwer, monitoring, naprawa błędów i dostosowanie do nowych wersji systemów. Nowych funkcji w nim nie ma, a ta granica jest najczęstszym źródłem sporów po starcie.

Zapisz w umowie każdą z poniższych pozycji osobno, razem z informacją, kto ją wykonuje:

• hosting i baza danych: koszt w abonamencie albo wprost wskazane, że płacisz go dostawcy;
• monitoring: ktoś dowiaduje się o awarii przed Twoimi klientami;
• naprawa błędów, czyli odstępstw od zakresu odebranego przy odbiorze;
• aktualizacje bezpieczeństwa i bibliotek, z których zbudowano aplikację;
• zgodność z nowymi wersjami iOS i Androida;
• kopie zapasowe wraz z próbą ich odtworzenia, nie samo ich tworzenie.

Rynkowy punkt odniesienia dla rocznego kosztu utrzymania to 15–25% kosztu budowy. Podaje go agencja Koombea we wpisie z 2023 r. (aktualizacja 05.2024, odczyt 19.10.2026), a jej przykład dla aplikacji za 200 000 USD to 30–50 tys. USD rocznie.

To dane firmy sprzedającej takie usługi, nie badanie rynku, więc użyj ich jako punktu startu do rozmowy.

Konta i infrastruktura to osobna rubryka rachunku. Apple Developer Program kosztuje 99 USD za rok członkostwa (Apple, odczyt 19.10.2026), a plan Pro w Supabase zaczyna się od 25 USD miesięcznie i obejmuje 8 GB dysku (Supabase, odczyt 19.10.2026).

Zapytaj wykonawcę, czy fakturuje takie opłaty dalej bez marży, czy wlicza je w abonament.

Co jest rozwojem i rozlicza się osobno?

Rozwojem jest każda zmiana, której nie było w zakresie odebranym przy odbiorze: nowa funkcja, nowy ekran, nowa integracja albo zmiana zasad działania. Poprawka błędu przywraca działanie zgodne z tym zakresem. Rozróżnienie jest proste tylko wtedy, gdy umowa mówi, do czego odnosi się słowo „błąd”.

Koombea zalicza naprawę błędów do utrzymania („Fixing bugs is an integral part of corrective maintenance.”) i zastrzega, że hosting jest wydatkiem, którego nie unikniesz (wpis z 2023 r., odczyt 19.10.2026). Poniższa tabela pokazuje, jak rozdzielić typowe sytuacje; to praktyka rynkowa do negocjacji, a nie przepis.

Rozwój rozlicza się zwykle jednym z trzech sposobów:

• stawka godzinowa: płacisz za przepracowany czas, a w umowie ustalasz miesięczny limit, powyżej którego wykonawca pyta o zgodę;
• pakiet godzin kupowany z góry: zapisz, czy niewykorzystane godziny przepadają, czy przechodzą na kolejny miesiąc;
• wycena zakresu: stała cena za opisaną zmianę, z zapisem, co się dzieje, gdy zakres urośnie w trakcie prac.

Dobra umowa każe wykonawcy oznaczyć każde zgłoszenie jako „błąd” albo „rozwój” w ciągu ustalonego czasu od jego otrzymania. Bez takiego zapisu klasyfikację robi strona, której zależy na fakturze.

Jak zapisać czas reakcji i dostępność w SLA?

SLA to zapis poziomu usługi, który wykonawca gwarantuje, a w małej aplikacji liczą się w nim dwie rzeczy: dostępność i czas reakcji. Dostępność podajesz w procentach razem z oknem pomiaru. Brak okna pomiaru sprawia, że liczba w umowie nic nie znaczy.

Autor poradnika na DEV Community opisuje to tak: SLA „defines the uptime a provider guarantees”. Przy 99,9% mierzonym miesięcznie wykonawca musi zapewnić mniej niż 43,8 minuty przestoju w miesiącu, a przy tym samym wyniku mierzonym rocznie wolno mu mieć do 8,76 godziny przestoju w roku (DEV Community, odczyt 19.10.2026).

Źródło: DEV Community: Understanding SaaS Service Level Agreements, odczyt 19.10.2026

Czas reakcji to moment, w którym ktoś zaczyna zajmować się zgłoszeniem. Czas naprawy to moment, w którym problem znika. Zapisz obie liczby osobno, bo zobowiązanie do samej reakcji nie gwarantuje, że aplikacja wróci do działania.

Propozycja do negocjacji (szacunek własny, nie standard rynkowy): awaria blokująca cały system dostaje reakcję do czterech godzin w dni robocze, a błąd kosmetyczny trafia do najbliższej planowej aktualizacji.

Dopisz, co nie liczy się jako przestój: planowane okna serwisowe i awarie dostawców, takich jak hosting czy sklepy z aplikacjami. Zapisz też rekompensatę za naruszenie SLA, na przykład obniżenie abonamentu za dany miesiąc.

Jakie zapisy chronią przed zatrzymaniem aplikacji?

Przed zatrzymaniem aplikacji chronią cztery rzeczy: prawo do zmian w kodzie, konta na Twoją firmę, jasne zasady wypowiedzenia i zakaz wyłączenia usługi w sporze o płatność. Każda z nich daje Ci możliwość zmiany wykonawcy bez przestoju. Brak którejkolwiek robi z umowy serwisowej smycz.

Pierwsza sprawa to prawo do zmian w kodzie. Licencja obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2 ustawy o prawie autorskim i prawach pokrewnych, odczyt 19.10.2026).

Prawa majątkowe do programu komputerowego obejmują m.in. jego zmiany (art. 74 ust. 4 tej ustawy).

Bez prawa do zmian w umowie ustawa dopuszcza tylko zmiany niezbędne do korzystania z programu zgodnie z przeznaczeniem, w tym poprawianie błędów, o ile umowa tego nie wyłącza (art. 75 ust. 1). Rozwój nowych funkcji przez nowego wykonawcę wymaga więc wyraźnego zapisu w umowie.

Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 tej ustawy, odczyt 19.10.2026). Szczegóły zapisów o prawach opisujemy w artykule Kto ma prawa do aplikacji zbudowanej na zlecenie, a ogólny układ umowy w tekście Co musi zawierać umowa na stworzenie aplikacji mobilnej.

Pozostałe trzy zabezpieczenia:

• konta: Apple Developer, Google Play, domena i hosting rejestrujesz na swoją firmę, bo przeniesienie aplikacji z konta wykonawcy może zainicjować tylko właściciel tamtego konta (Apple: „Your membership Account Holder initiates the app transfer.”, odczyt 19.10.2026);
• wypowiedzenie: okres jest wyraźnie zapisany, a w ostatnim okresie rozliczeniowym wykonawca przekazuje kod, dostępy i dokumentację bez dodatkowej opłaty;
• ciągłość: wykonawca nie ma prawa wyłączyć ani zablokować aplikacji z powodu spornej faktury.

Więcej o kosztach utrzymania przez kolejne lata znajdziesz w tekście Ile kosztuje utrzymanie aplikacji przez rok i przez kolejne lata. Pozostałe sprawy umów porządkuje dział Prawo i podatki.

Jak sprawdzić ofertę serwisową przed podpisem?

Ofertę serwisową sprawdzasz w pięciu krokach, które zajmują jedno popołudnie i zamykają najczęstsze luki.

1. Poproś o zakres abonamentu w punktach i o definicję „błędu” oraz „rozwoju”.
2. Zapytaj, które opłaty infrastrukturalne wykonawca wlicza w abonament, a które fakturuje dalej.
3. Przelicz abonament roczny na procent kosztu budowy i porównaj z widełkami 15–25% (Koombea, wpis z 2023 r., odczyt 19.10.2026).
4. Wpisz SLA z oknem pomiaru oraz osobnymi czasami reakcji i naprawy.
5. Sprawdź prawa do kodu, właściciela kont i zasady wypowiedzenia.

Jeśli w trzech z tych pięciu punktów oferta milczy, nie podpisuj jej bez poprawek. Kiedy chcesz przejść przez swoją ofertę razem z kimś, kto zna budowę aplikacji od środka, zacznij od bezpłatnej rozmowy.

Kiedy podpisać umowę serwisową: razem z budową czy po starcie?

Umowę serwisową podpisujesz razem z umową o budowę albo tuż przed odbiorem. Po starcie tracisz argument, który daje Ci niezakończona płatność za budowę. Wykonawca wie wtedy, że jesteś od niego zależny, i wycenia abonament bez konkurencji.

Zanim podpiszesz, poproś o dokument odbiorczy z listą funkcji, bo to on definiuje, co jest błędem, a co rozwojem. Termin odbioru zależy od etapów budowy, które opisuje tekst Ile trwa stworzenie aplikacji i ile tygodni zajmuje każdy etap.

Wartość abonamentu sprawdzisz po pierwszym kwartale, porównując faktyczne godziny rozwoju z tym, co zapisano.