Utrzymanie aplikacji: co to właściwie oznacza i czy Twoja aplikacja go potrzebuje?

Aplikacja działa poprawnie. Użytkownicy nie zgłaszają problemów, nie zamawiałeś żadnych nowych funkcji, ostatnią zmianę w kodzie zlecałeś pół roku temu. A mimo to co miesiąc otrzymujesz fakturę za utrzymanie aplikacji.

Za co właściwie płacisz, skoro nic się nie zmienia? Odpowiedź „za utrzymanie” niczego nie wyjaśnia, bo nie mówi, co się za nią kryje.

Jeśli twoja aplikacja dopiero powstaje, to samo pytanie czeka cię zaraz po jej uruchomieniu. Uwzględnij więc w swoim budżecie koszty utrzymania aplikacji. Jak duże? Odpowiadamy poniżej.

W tym artykule tłumaczymy, co dokładnie mieści się w utrzymaniu aplikacji, czy można z niego zrezygnować, ile godzin miesięcznie zwykle zajmuje i jak wygląda jego cykl. Wyjaśniamy też, co właściwie podpisujesz w umowie na utrzymanie: czym różnią się błędy krytyczne od pozostałych i kiedy całodobowa gotowość zespołu ma sens, a kiedy jest zbędnym wydatkiem.

Czym jest utrzymanie aplikacji, a czym nie jest

Potrzeba utrzymania wynika z prostego faktu: nawet jeśli kod aplikacji się nie zmienia, zmienia się jej otoczenie.

Na to otoczenie składa się wszystko, na czym aplikacja się opiera. Aplikacja webowa działa w przeglądarce i na serwerze, a mobilna na telefonie z iOS albo z Androidem. Obie korzystają z bibliotek open source, rozwijanych niezależnie od wykonawcy, oraz z usług zewnętrznych firm, takich jak operator płatności czy dostawca map.

Każdy z tych elementów jest regularnie zmieniany przez swojego twórcę, a te zmiany często bezpośrednio dotykają aplikacji. Nowa wersja Androida ogranicza na przykład działanie aplikacji w tle i aplikacja kurierska przestaje na bieżąco przesyłać lokalizację kierowcy. Przeglądarka zaostrza zasady dotyczące plików cookie i w aplikacji webowej przestaje działać logowanie przez zewnętrzny serwis. W żadnym z tych przypadków nikt nie zmienił ani jednej linijki kodu aplikacji.

W aplikacjach mobilnych dochodzą do tego wymagania sklepów. Apple i Google co roku podnoszą wymagania techniczne wobec aplikacji publikowanych w App Store i Google Play, więc nawet aplikacja, w której nic się nie zmienia, musi być regularnie przebudowywana.

Dlatego utrzymanie nie polega wyłącznie na reagowaniu, gdy aplikacja przestaje działać. Gotowość na awarię jest jego częścią, ale zajmuje najmniej czasu. Większość pracy wykonuje się po to, żeby do awarii w ogóle nie dochodziło. Aplikację aktualizuje się na bieżąco, zanim któraś ze zmian w otoczeniu zdąży ją zepsuć.

Ta praca dzieli się na cztery rodzaje:

• Naprawa błędów. Użytkownicy zgłaszają, że aplikacja zamyka się przy próbie zapisania zdjęcia. Zespół znajduje przyczynę i publikuje poprawkę. To jedyna część utrzymania, którą większość osób intuicyjnie kojarzy z tym pojęciem.
• Nadążanie za zmianami w otoczeniu aplikacji. Operator płatności udostępnia nową wersję swojego systemu i po kilku miesiącach wyłącza starą. Jeśli aplikacja nie zostanie na czas przepięta, płatności przestają przechodzić. Sama z siebie aplikacja się do tego nie dopasuje.
• Zapobieganie problemom, zanim się pojawią. Najczęstszy przykład dotyczy bezpieczeństwa. W jednej z bibliotek wykorzystywanych w aplikacji zostaje wykryta luka. Zespół wymienia ją na bezpieczniejszą wersję i zamyka temat, zanim ktokolwiek zdąży tę lukę wykorzystać.
• Ulepszanie tego, co już działa. Lista produktów ładuje się cztery sekundy, a zespół skraca ten czas do jednej. Nic nie było zepsute, ale korzystanie z aplikacji stało się wygodniejsze.

W literaturze branżowej te cztery obszary nazywa się kolejno utrzymaniem korekcyjnym, adaptacyjnym, prewencyjnym i perfekcyjnym. Nazwy nie są istotne, istotny jest podział.

Zwróć uwagę na dwa środkowe punkty, czyli adaptację i prewencję. To prace, których nikt nie zamawia i których użytkownicy nie zauważą. Powstają dlatego, że otoczenie aplikacji się zmienia, nawet jeśli sam kod aplikacji się nie zmienił.

Gdzie kończy się utrzymanie, a zaczyna rozwój

Jest jeszcze jeden rodzaj prac, który często wrzuca się do tego samego worka: dodawanie nowych funkcji. Formalnie nie jest to utrzymanie, tylko rozwój produktu, i zwykle rozlicza się je osobno.

W stałej opiece nad aplikacją zazwyczaj mieszczą się:

• monitorowanie działania aplikacji i reagowanie na awarie,
• naprawa zgłoszonych błędów,
• aktualizacje bibliotek i narzędzi, w tym łatanie wykrytych luk bezpieczeństwa,
• obowiązkowe aktualizacje wymagane przez sklepy z aplikacjami,
• drobne poprawki i usprawnienia,
• raportowanie wykonanych prac.

Osobno wycenia się natomiast prace takie jak:

• nowe moduły i większe funkcjonalności,
• przeprojektowanie interfejsu,
• pełny audyt bezpieczeństwa i testy penetracyjne,
• przebudowa architektury aplikacji,
• dodatkowe integracje z systemami zewnętrznymi.

Warto rozróżnić dwie rzeczy, które nazywa się tak samo. Wymiana biblioteki z wykrytą luką to zwykle kilka godzin pracy i mieści się w stałej opiece. Pełny audyt bezpieczeństwa, w którym specjaliści próbują aplikację zaatakować, żeby sprawdzić, gdzie da się ją złamać, może trwać nawet parę dni i zleca się go osobno.

Ustalenie tej granicy na początku współpracy oszczędza potem sporo nerwów obu stronom. Kiedy pozostaje ona nieostra, klient zaczyna mieć poczucie, że płaci za nic, bo nie widzi żadnych efektów. Wykonawca z kolei dostaje kolejne „drobne prośby”, które w skali miesiąca sumują się w kilka dni pracy, ale nie ma jak ich rozliczyć.

Dlatego zanim podpiszesz cokolwiek, poproś o konkretny wykaz tego, co wchodzi w opiekę, a co będzie wyceniane osobno.

Czy utrzymanie aplikacji jest obowiązkowe?

Nie musisz podpisywać żadnej umowy na utrzymanie. Możesz odebrać gotową aplikację, zapłacić ostatnią fakturę za jej budowę i nie wydać już ani złotówki.

Tylko że nie tu leży prawdziwe pytanie. Nie chodzi o to, czy podpiszesz umowę, ale o to, czy przy aplikacji pojawi się praca do wykonania. A ona pojawi się niezależnie od twojej decyzji, ponieważ generują ją strony trzecie, na które nie masz żadnego wpływu.

Poniżej dwa najczęstsze przykłady.

Sklepy z aplikacjami wyznaczają terminy, których nie negocjujesz

Wymagania techniczne, które Apple i Google stawiają aplikacjom, to nie są sugestie ani dobre praktyki, tylko warunki dopuszczenia do dystrybucji. W 2026 roku wygląda to następująco:

• Od 28 kwietnia każda aplikacja wysyłana do App Store musi być zbudowana przy użyciu najnowszego zestawu narzędzi programistycznych Apple.
• Od 31 sierpnia Google Play wymaga, aby nowe aplikacje i aktualizacje były przygotowane pod najnowszą wersję Androida, a aplikacje już opublikowane spełniały wymóg z poprzedniego roku.

W 2027 pojawią się kolejne terminy, a rok później następne. To nie jest jednorazowa operacja, po której temat się zamyka, tylko stały rytm, w którym każda aplikacja obecna w sklepie musi zostać przebudowana i przetestowana.

Konsekwencja zignorowania terminu jest mniej oczywista, niż mogłoby się wydawać. Dotychczasowi użytkownicy mogą dalej korzystać z aplikacji, więc na pierwszy rzut oka nic się nie dzieje. Tracisz jednak możliwość publikowania jakichkolwiek aktualizacji, a przy poważnym błędzie oznacza to, że nie naprawisz go, dopóki nie nadrobisz wszystkich zaległości. W Google Play dochodzi drugi skutek: aplikacja przestaje być dostępna dla nowych użytkowników, których telefony działają na nowszej wersji Androida niż ta, pod którą została przygotowana.

Usługi, na których oparta jest twoja aplikacja

Druga sytuacja jest jeszcze mniej intuicyjna, ponieważ nie ma tu żadnego terminu w kalendarzu ani ostrzeżenia w panelu.

Powiadomienia, mapy, płatności, logowanie przez konto Google czy Facebook, analityka. Takich funkcji nie buduje się od zera, tylko korzysta z gotowych usług innych firm. Problem polega na tym, że te firmy zamykają swoje usługi, kiedy przestają im się opłacać.

W sierpniu 2025 roku Google wyłączył Firebase Dynamic Links, usługę obsługującą linki, które otwierają konkretne miejsce w aplikacji. Korzystały z niej tysiące aplikacji na całym świecie. Dla ich właścicieli sytuacja wyglądała tak samo: niczego nie zmieniali, a mimo to część aplikacji przestała działać poprawnie. Trzeba było zlecić przepisanie tego fragmentu na inne rozwiązanie i za tę pracę zapłacić. W naszym portfolio jedna decyzja Google wymusiła zmiany w kilku aplikacjach jednocześnie.

Tak właśnie najczęściej wygląda utrzymanie. Nie jest to sprzątanie po własnych błędach, tylko nadążanie za światem, który zmienia się wokół twojej aplikacji.

Czyli można nie mieć utrzymania?

Można nie mieć umowy. Nie da się jednak całkiem uniknąć pracy przy aplikacji.

Różnica polega wyłącznie na tym, kiedy tę pracę wykonasz i na jakich warunkach. Przy stałej opiece rozkłada się ona na kilka godzin miesięcznie. Dzięki temu wiesz z góry, ile to kosztuje, i możesz spać spokojnie.

Bez stałej opieki praca kumuluje się i wraca w najgorszym możliwym momencie, zwykle wtedy, gdy aplikacja przestaje działać, a ty potrzebujesz naprawy natychmiast.

Jest jednak sytuacja, w której da się utrzymanie ograniczyć do minimum. Jeśli aplikacja jest prosta, nie ma własnego backendu, nie korzysta z wielu usług zewnętrznych i nie przetwarza wrażliwych danych, może wystarczyć opieka bez stałej puli godzin, zlecana wtedy, gdy pojawia się konkretna potrzeba, na przykład nowy wymóg sklepu.

Co się dzieje, gdy odpuścisz na dwa lata

Skutek zaniedbania odczujesz dopiero w momencie, w którym zechcesz cokolwiek w aplikacji zmienić. Zgłaszasz drobną poprawkę, taką na jeden dzień pracy, i słyszysz wycenę na trzy tygodnie.

Nie wynika to z tego, że sama poprawka jest trudna. Problem polega na tym, że nie da się jej wdrożyć bez uporządkowania wszystkiego, co przez te dwa lata zostało pominięte.

Zaległe aktualizacje nie sumują się bowiem jedna do drugiej. Nie masz do nadrobienia dwudziestu kilku drobnych zmian, tylko jedną wielką przebudowę. Elementy aplikacji są ze sobą powiązane, więc podniesienie wersji jednego wymusza zmiany w kilkunastu innych.

Osobno każda z tych zmian byłaby prosta: aktualizujesz jeden element, sprawdzasz miejsca, w których jest używany, i temat się zamyka. Przy kilkunastu elementach jednocześnie każda zmiana może jednak zepsuć coś w zupełnie innym miejscu aplikacji, a gdy pojawia się błąd, najtrudniejsze jest ustalenie, która ze zmian go wywołała.

Dlatego te trzy tygodnie z wyceny to w większości nie aktualizowanie, ale sprawdzanie, czy wszystko nadal działa.

Jak wygląda cykl utrzymania aplikacji w ramach umowy SLA

Na pytanie, ile godzin miesięcznie zajmuje utrzymanie, nie ma jednej odpowiedzi. W praktyce nie zgaduje się jej zresztą z góry, tylko ustala w umowie SLA.

SLA, czyli Service Level Agreement, to umowa określająca zasady obsługi aplikacji. Opisuje, jak zgłasza się problemy, jak są one priorytetyzowane, w jakim czasie zespół reaguje, w jakich godzinach jest dostępny, jak wygląda eskalacja trudnych spraw i jak rozlicza się wykonaną pracę.

Pula godzin i droga zgłoszenia

Najczęściej spotykany model opiera się na miesięcznej puli godzin. Ustalasz z wykonawcą, ile czasu zespół ma do dyspozycji w każdym miesiącu. Przy aplikacjach o małym lub średnim stopniu skomplikowania pula wynosi zwykle od 6 do 24 godzin miesięcznie.

Pula obejmuje także sytuacje, których nikt nie zaplanuje: awarię u dostawcy płatności, nagłą zmianę w zewnętrznym systemie czy błąd, który ujawnia się tylko na jednym modelu telefonu. Takie rzeczy zdarzają się w każdym projekcie, dlatego pulę warto ustalić z zapasem.

Zgłoszenia trafiają do zespołu jednym, ustalonym kanałem, na przykład przez system zgłoszeń. Każde z nich przechodzi tę samą drogę:

zgłoszenie → kwalifikacja → priorytet → określenie zakresu → realizacja → testy → wdrożenie → zamknięcie i raport

Najważniejszy jest drugi krok. Na etapie kwalifikacji zespół sprawdza, czy zgłoszenie w ogóle należy do utrzymania. Naprawa błędu czy dostosowanie aplikacji do zmiany w systemie mieści się w puli. Nowa funkcja albo większa przebudowa jest już osobno wyceniana i nie powinna być automatycznie traktowana jako praca w ramach SLA.

Po każdym miesiącu dostajesz raport z wykorzystania godzin. Widzisz w nim, jakie zgłoszenia zostały obsłużone i ile czasu zajęło każde z nich. Dzięki temu dokładnie wiesz, za co płacisz.

Przykładowy cykl prac

Poza obsługą zgłoszeń część pracy wykonuje się niezależnie od nich. Jej rytm w większości projektów wygląda podobnie.

Na bieżąco zespół monitoruje działanie aplikacji, raporty o awariach i bezpieczeństwo używanych bibliotek. Nie jest to zadanie wykonywane raz w miesiącu, bo luka w bibliotece może zostać ujawniona w każdej chwili i wtedy trzeba zareagować od razu.

Regularnie, co kilka tygodni albo co kwartał, aktualizuje się biblioteki i przegląda wydajność aplikacji oraz koszty serwerów.

Kilka razy w roku, często bez stałego harmonogramu, pojawiają się większe zmiany wymuszone z zewnątrz. Nowe wersje iOS i Androida, z którymi aplikacja musi pozostać zgodna. Nowe wymagania App Store i Google Play. Zmiany w API zewnętrznych dostawców, z którymi aplikacja się łączy. Wygasające certyfikaty, które potwierdzają bezpieczeństwo połączenia i mają określoną datę ważności. Terminy tych prac wyznacza ktoś inny, a ich zakres zależy od tego, co dokładnie się zmieniło.

Co wpływa na wielkość puli godzin

Pula będzie bliżej górnej granicy, jeśli aplikacja ma własny backend i bazę danych, korzysta z wielu usług zewnętrznych, obsługuje płatności, przetwarza dane osobowe albo działa w branży objętej regulacjami. Każdy z tych elementów to osobny obszar, który trzeba doglądać.

Będzie bliżej dolnej granicy, jeśli aplikacja jest prosta, ma niewiele integracji i nie ma zaległości w aktualizacjach.

Największą różnicę robią jednak testy automatyczne, czyli coś, na czym przy budowie najłatwiej zaoszczędzić. Aplikacja, która ma je od początku, jest tańsza w utrzymaniu, bo każda aktualizacja wymaga mniej ręcznego sprawdzania. Koszt ponosisz raz, a odzyskujesz go przez cały czas, kiedy aplikacja działa.

Priorytety, czasy reakcji i godziny wsparcia

Możesz dostać dwie oferty na utrzymanie tej samej aplikacji, z podobną pulą godzin, różniące się ceną nawet kilkukrotnie. To nie musi oznaczać, że któraś jest nieuczciwa. Najczęściej różnią się tym, jak szybko i w jakich godzinach zespół reaguje na zgłoszenia.

Nie każdy błąd jest tak samo pilny

Każda sensowna umowa dzieli zgłoszenia na kilka poziomów, najczęściej oznaczanych jako P1, P2 i P3. Nazewnictwo bywa różne, ale logika jest wszędzie podobna.

• Błąd krytyczny (P1) to taki, który uniemożliwia korzystanie z aplikacji albo z jej najważniejszej funkcji. Aplikacja nie uruchamia się, nie da się zalogować, płatności nie przechodzą.
• Błąd funkcjonalny (P2) to sytuacja, w której część aplikacji działa niepoprawnie, ale nadal da się z niej korzystać. Na przykład wyszukiwarka nie znajduje części produktów, choć można je znaleźć przez kategorie, albo powiadomienia przychodzą z opóźnieniem.
• Błąd drobny (P3) dotyczy wyglądu albo szczegółów, które nie wpływają na działanie. Przycięty tekst na jednym modelu telefonu, literówka, ikona w złym kolorze.

O priorytecie nie decyduje to, jak bardzo błąd cię irytuje, tylko to, ilu użytkowników blokuje i czy mają jakiekolwiek wyjście. Jeśli podział w umowie jest nieostry, przy pierwszym poważnym zgłoszeniu obie strony będą się spierać o to, czy sytuacja kwalifikuje się jako krytyczna.

Czas reakcji to nie czas naprawy

Zapis o reakcji w ciągu dwóch godzin nie oznacza, że w ciągu dwóch godzin błąd zniknie. Oznacza, że w tym czasie zespół potwierdzi przyjęcie zgłoszenia, oceni jego wagę i rozpocznie analizę. Sama naprawa może zająć godzinę albo trzy dni.

Dlatego dobra umowa określa osobno czas reakcji i czas rozwiązania dla każdego priorytetu. Opisuje też ścieżkę eskalacji, czyli to, do kogo trafia sprawa, gdy zgłoszenie krytyczne nie zostaje rozwiązane w ustalonym czasie.

Kiedy całodobowa gotowość ma sens

Standardowo zespół jest dostępny w dni robocze, w godzinach pracy. Wsparcie przez całą dobę, siedem dni w tygodniu, najmocniej podnosi cenę umowy, bo płacisz wtedy nie tylko za pulę godzin, ale także za gotowość zespołu.

Nie wystarczy jedna osoba z telefonem przy łóżku, bo ta osoba śpi, choruje i bierze urlop. Potrzebny jest grafik dyżurów obejmujący kilka osób, wynagrodzenie za samą dyspozycyjność i procedury opisujące, co robić przy konkretnych awariach. Te koszty ponosisz co miesiąc, także wtedy, gdy nic się nie wydarzy.

Całodobowa gotowość ma sens wtedy, gdy przestój od razu powoduje realną szkodę. Dotyczy to przede wszystkim trzech sytuacji:

• aplikacji opartych na transakcjach, na przykład dużego sklepu internetowego czy obsługi płatności, gdzie każda godzina niedziałania oznacza bezpośrednie straty,
• systemów związanych ze zdrowiem lub bezpieczeństwem, gdzie przestój przestaje być wyłącznie problemem finansowym,
• aplikacji wspierających procesy, których nie da się zatrzymać, jak produkcja czy logistyka.

Jeśli natomiast przestój oznacza tylko tyle, że użytkownik skorzysta z aplikacji kilka godzin później, gotowość całodobowa jest wydatkiem bez pokrycia. Awaria o drugiej w nocy zostanie zauważona rano i naprawiona tego samego dnia.

Sprawdzian jest prosty: oblicz, ile realnie kosztują cię cztery godziny niedziałania aplikacji. Jeśli ta kwota jest niższa niż roczna różnica w cenie umowy, nie potrzebujesz dyżurów. Jeśli jest wyższa, dyżury się opłacają.

Jak zgłosić błąd, żeby szybciej go naprawić

Sposób, w jaki zgłosisz błąd, realnie wpływa na to, jak szybko zostanie naprawiony. Większość błędów pojawia się bowiem tylko w określonych warunkach, na przykład na telefonach jednego producenta albo przy konkretnej wersji systemu. Zanim ktokolwiek zabierze się do naprawy, musi najpierw ten błąd u siebie zobaczyć.

Dlatego przy zgłoszeniu zwykle wymaga się podania modelu telefonu, wersji systemu i dokładnego opisu tego, co użytkownik robił, gdy problem wystąpił. Przy takim opisie odtworzenie sytuacji zajmuje kilkanaście minut. Przy zgłoszeniu w stylu „aplikacja nie działa” znaczna część czasu schodzi na ustalanie, kiedy właściwie nie działa, a ten czas analizy również jest odliczany z puli godzin.

Podsumowanie

Utrzymanie aplikacji nie polega głównie na naprawianiu awarii. Większość pracy generują terminy narzucane przez sklepy z aplikacjami i zmiany w usługach zewnętrznych, z których korzysta twoja aplikacja. Ani jedno, ani drugie nie zależy od ciebie.

Co warto zapamiętać:

• Umowy można nie mieć, pracy nie da się uniknąć. Pytanie brzmi tylko, czy rozłożysz ją na kilka godzin miesięcznie, czy zapłacisz za nią jednorazowo, w gorszym momencie i po wyższej stawce.
• Nie każda aplikacja potrzebuje tego samego. Prosty produkt bez backendu i integracji może nie potrzebować stałej puli godzin. Sklep obsługujący płatności to zupełnie inna rozmowa. Zanim zaczniesz porównywać oferty, ustal, w którym z tych scenariuszy jesteś.
• Porównując oferty, patrz na warunki, a nie tylko na kwotę. Sprawdź wielkość miesięcznej puli godzin, podział priorytetów z czasami reakcji i rozwiązania, godziny dostępności zespołu oraz to, czy dostajesz raport z wykorzystania godzin.

Jeśli masz już aplikację i nie wiesz, w jakim jest stanie, zacznij od przeglądu technicznego. Sprawdza się w nim, czy wykorzystane technologie są aktualne, czy aplikacja spełnia obecne wymagania sklepów i czy nie ma w niej znanych luk bezpieczeństwa.