Jeśli aplikacja działa, czy możemy ją zostawić bez opieki? Co naprawdę obejmuje utrzymanie aplikacji

Czy aplikację, która działa, można zostawić bez opieki? Można, ale tylko na krótko i na własne ryzyko. Sama aplikacja się nie psuje, ale wszystko wokół niej się zmienia. W wielu firmach scenariusz jest ten sam: aplikacja działa, firma przestaje płacić za utrzymanie i wraca do programisty dopiero po awarii albo z prośbą o nową funkcję. Wtedy przed jakąkolwiek zmianą trzeba nadrobić wszystkie odłożone aktualizacje.

Odpowiedź wprost

Nie bez konsekwencji. Aplikacja, która dziś działa, jutro może przestać, bo zmieniają się biblioteki, systemy, wymagania sklepów i metody ataków. Bez regularnych aktualizacji, monitoringu, sprawdzonych kopii zapasowych i analizy użycia reagujesz dopiero na awarię, w terminie, którego nie wybierasz. Utrzymanie aplikacji to stała, planowana praca, a nie naprawa na żądanie.

Piszę jako programista PHP (Symfony, Laravel), który przejmuje, migruje i utrzymuje aplikacje firmowe. Daty i przepisy: stan na 02.11.2026.

W skrócie: dlaczego „działa” to za mało

„Działa” znaczy tylko tyle, że dziś nic się nie zepsuło i nikt jeszcze nie wykorzystał luki.

Pięć rzeczy starzeje się, nawet gdy nikt aplikacji nie dotyka:

1. Zależności: biblioteki i frameworki dostają poprawki, a starsze wersje przestają je dostawać.
2. Systemy: język, środowisko uruchomieniowe, serwer i baza danych mają daty końca wsparcia.
3. Wymagania sklepów: Google Play i Apple regularnie podnoszą wymagania wobec aktualizacji.
4. Metody ataków: znane podatności są wykorzystywane coraz szybciej.
5. Wiedza o kodzie: ludzie zapominają i odchodzą, dokumentacja się dezaktualizuje.

Czy trzeba aktualizować aplikację, która działa? Tak, jeśli któryś z tych elementów traci wsparcie albo ma znaną lukę, a prędzej czy później dotyczy to każdej aplikacji. Utrzymanie aplikacji po wdrożeniu pilnuje tych pięciu rzeczy, zanim zamienią się w awarię.

Model „płacę, gdy się zepsuje”: dlaczego tak wielu CEO tak działa i ile to kosztuje

Wielu CEO wybiera model „naprawiamy dopiero, jak się zepsuje”, bo koszt opieki widać co miesiąc na fakturze, a koszt jej braku dopiero w dniu awarii. Ten drugi składa się z przestoju, pracy w pośpiechu, wstrzymanych zamówień i czasu zarządu.

Cztery najczęstsze obiekcje i odpowiedzi:

„Dostałem działającą aplikację.” Odbiór potwierdza, że aplikacja działała w dniu odbioru, na ówczesnych wersjach bibliotek i systemów. Gwarancja obejmuje błędy wykonawcy, a nie zmiany wokół aplikacji.

„Płacimy tylko za awarie.” Przy poważniejszej awarii wykonawca najpierw przypomina sobie system, często aktualizuje przestarzałe elementy, żeby w ogóle wdrożyć poprawkę, i robi to w terminie narzuconym przez awarię, o ile ma wolny termin.

„To drogie.” Zakres opieki dobiera się do wagi aplikacji: proste narzędzie nie potrzebuje dyżuru, system sprzedażowy tak.

„Nikt nas nie zaatakuje.” Atakujący nie muszą wiedzieć, kim jesteś. Wystarczy znana, niezałatana luka, a szukanie takich luk da się zautomatyzować.

Reaktywnie czy zapobiegawczo: porównanie

Model reaktywny jest tańszy w spokojnym miesiącu, a zapobiegawczy w miesiącu, w którym coś się dzieje.

Dług technologiczny, czyli odsetki od odkładania

Dług technologiczny to zaległe aktualizacje i uproszczenia w kodzie, za które płaci się później z odsetkami: każda odłożona wersja podnosi koszt i ryzyko kolejnej zmiany. Jak to wygląda na przykładzie jednej platformy, opisałem w tekście o tym, czym grozi zwlekanie, czyli aktualizacja PHP w firmie.

Z mojej praktyki: aktualizacja serwera, języka programowania czy frameworka robiona po kilku miesiącach przerwy to często koszt 2 000–4 000 zł i 2-3 dni pracy. Gdy dba się o to na bieżąco, każda zmiana jest mniejsza, a aplikacja bezpieczniejsza.

Co się zmienia wokół aplikacji, gdy nikt jej nie dotyka

Gdy nikt aplikacji nie dotyka, rośnie lista znanych luk w jej komponentach, a kolejne wersje języka, frameworka i systemu tracą wsparcie.

Według raportu Verizon DBIR 2026 z 19.05.2026 wykorzystanie podatności było punktem wejścia w 31% naruszeń, wobec 20% rok wcześniej. Ten sam raport (PDF, 19.05.2026) podaje, że w 2025 r. w pełni załatano tylko 26% krytycznych podatności z katalogu CISA KEV, a mediana czasu pełnej naprawy wyniosła 43 dni. To dane globalne, ale wniosek jest prosty: aktualizacje aplikacji i bezpieczeństwo to proces, a nie jednorazowa akcja.

Według IBM Cost of a Data Breach 2026 z 29.07.2026 średni globalny koszt naruszenia danych wyniósł 4,99 mln USD, a IBM podkreśla, że długa luka między wykryciem a naprawą przekłada się wprost na koszt. To średnia globalna, nie dla polskich MŚP.

Czy stara aplikacja jest niebezpieczna? Nie wiek kodu, tylko komponenty bez poprawek i brak kogoś, kto o nich wie.

Kalendarz „co wygasa i kiedy” (stan na 02.11.2026)

Te daty dotyczą wielu firmowych aplikacji webowych i mobilnych.

Aplikacja niespełniająca wymagań Google nie znika z Google Play: według Google (odczyt 02.11.2026) nie zainstalują jej nowi użytkownicy z nowszym Androidem, a aplikacje trwale prywatne, dystrybuowane tylko w organizacji, są z wymagań wyłączone. Poprawek bezpieczeństwa i tak potrzebują. Wymóg Apple dotyczy budowania, więc bez aktualnego środowiska nie wyślesz do sklepu nawet pilnej poprawki. Więcej o aplikacjach mobilnych.

Co obejmuje opieka nad aplikacją

Opieka nad aplikacją obejmuje wszystko, co utrzymuje ją bezpieczną, dostępną i gotową do zmian, a do każdego punktu powinien istnieć dowód, który widzi właściciel. Tak w praktyce wygląda odpowiedź na pytanie, co obejmuje utrzymanie aplikacji:

W projektach, które utrzymuję, aktualizacje robię 1–2 razy w miesiącu, zależnie od sytuacji. Pozostałe częstotliwości w tabeli to ogólne zalecenia, nie norma.

W dobie AI ten temat jest jeszcze ważniejszy, bo nowe podatności pojawiają się co chwilę. Według Verizon DBIR 2026 z 19.05.2026 atakujący używają AI, żeby szybciej wykorzystywać znane podatności, co skraca czas na obronę z miesięcy do godzin. Przykłady z ostatnich tygodni:

• PHP: wydania PHP 8.4.26 i 8.5.11 z 24.09.2026 załatały m.in. CVE-2026-91766, czyli wyciek danych uwierzytelniających do innej domeny przy przekierowaniach w obsłudze adresów HTTP (ChangeLog PHP).
• Laravel: 23.10.2026 opublikowano krytyczną podatność CVE-2026-114509 w TokenGuard, przez którą przy bazie MySQL lub MariaDB można było uwierzytelnić się jako inny użytkownik API bez jego tokenu; poprawki są w Laravel 12.68.0 i 13.29.0.
• Debian: 21.10.2026 Debian wydał DSA-6575-1 dla nginx, łatające m.in. CVE-2026-15176, czyli przepełnienie bufora, które przy określonej konfiguracji pozwala wywołać restart procesu serwera, a w pewnych warunkach wykonać kod.

Utrzymanie a rozwój: gdzie kończy się abonament

Abonament kończy się tam, gdzie zaczyna się nowa funkcja: utrzymanie dba o to, co już jest, a rozwój dodaje to, czego jeszcze nie ma. Zmiana pola w formularzu zwykle mieści się w puli godzin. Nowy moduł albo integracja to osobny budżet i osobna wycena. Stały rozwój i utrzymanie istniejących systemów prowadzę w ramach usługi rozwój aplikacji.

Jak sprawdzić, czy opieka jest naprawdę robiona

Opieka jest robiona, jeśli co miesiąc dostajesz dowody, a nie zapewnienia. Poproś o raport miesięczny, listę zaktualizowanych komponentów z wersjami, wynik ostatniego próbnego odtworzenia kopii, listę zgłoszeń z czasami i zestawienie dostępności z monitoringu. Szerzej o tym, jak kontrolować software house bez wiedzy technicznej.

Bezpieczeństwo i kopie zapasowe: kopia bez testu niczego nie gwarantuje

Kopia zapasowa chroni firmę dopiero wtedy, gdy ktoś sprawdził, że da się z niej odtworzyć dane w rozsądnym czasie.

Art. 32 ust. 1 rozporządzenia 2016/679 (stan prawny na 02.11.2026) wymaga m.in. zdolności do szybkiego przywrócenia dostępności danych po incydencie (lit. c) oraz regularnego testowania, mierzenia i oceniania skuteczności zabezpieczeń (lit. d).

Jako analogię warto znać sprawę opisaną przez UODO 27.06.2023: po ataku ransomware serwer z dodatkową kopią uległ awarii, a dane odzyskano dopiero po prawie trzech miesiącach. Prezes UODO nałożył na burmistrza 30 tys. zł kary, m.in. za nieprzetestowane zabezpieczenia, i przypomniał, że testowanie musi być regularne. To podmiot publiczny i system operacyjny, więc traktuj to jako analogię.

Co robić w pierwszych godzinach po awarii i kiedy zgłosić wyciek do UODO, opisałem w tekście o tym, kto odpowiada za kod AI.

Fragmenty o RODO to nie porada prawna i wymagają przejrzenia przez prawnika.

Monitoring, czyli wiedzieć przed klientem

Monitoring aplikacji ma jeden cel: żebyś o problemie dowiedział się od systemu, a nie od klienta. Automatycznie sprawdza, czy aplikacja odpowiada z zewnątrz, jakie błędy zgłasza, jak szybko działają kluczowe operacje, czy działają zadania w tle (maile, importy, płatności) oraz kiedy kończy się miejsce na serwerze i ważność certyfikatów. Alert musi trafiać do konkretnej osoby, a nie do nieczytanej skrzynki.

Kopie zapasowe i test odtworzenia

Kopie zapasowe aplikacji to połowa pracy, a drugą połową jest próbne odtworzenie. Dopóki kopia nie przeszła takiej próby, nie wiesz, czy masz kopię, czy plik o obiecującej nazwie. Dobra praktyka:

• kopiuj bazę i pliki (załączniki, konfigurację),
• trzymaj kopie poza serwerem produkcyjnym,
• odtwarzaj próbnie na osobnym środowisku i zapisuj, ile to trwało,
• ustal, ile danych możesz stracić: z godziny czy z dnia.

Analiza zachowań użytkowników: o czym decydujesz na ślepo

Bez analityki decyzje o rozwoju aplikacji zapadają na ślepo: nie wiesz, z których funkcji ludzie korzystają, gdzie się gubią i za utrzymanie czego płacisz, choć nikt tego nie używa.

Dlatego analiza zachowań użytkowników to element opieki. Nieużywana funkcja kosztuje przy każdej aktualizacji, a proces porzucany w tym samym miejscu to gotowy temat na poprawkę.

Przykład z BeautyDoc: dzięki danym o zachowaniach użytkowników skróciliśmy czas rejestracji z kilku minut do 30 sekund i wprowadziliśmy onboarding, który prowadzi początkujących użytkowników krok po kroku.

W aplikacjach publicznych pamiętaj o zgodzie. Art. 399 ustawy Prawo komunikacji elektronicznej (obowiązuje od 10.11.2024, stan na 02.11.2026) wymaga informacji i zgody przed zapisaniem lub odczytaniem informacji na urządzeniu użytkownika, a analityka zwykle nie mieści się w wyjątkach. Analityka wśród pracowników to osobne pytanie (RODO, prawo pracy). To nie porada prawna; fragment wymaga przejrzenia przez prawnika.

Co mierzyć w aplikacji firmowej

Mierz to, co pomaga podjąć decyzję:

• ile osób faktycznie korzysta z aplikacji w tygodniu i w miesiącu,
• które funkcje są używane, a które prawie wcale,
• na którym kroku ludzie porzucają kluczowe procesy (zamówienie, rejestrację, formularz),
• błędy widoczne dla użytkownika i czas najważniejszych operacji,
• wyszukiwania bez wyników i ekrany, z których przychodzi najwięcej zgłoszeń.

Zacznij od trzech do pięciu pytań zarządu.

SLA bez żargonu: reakcja, obejście, naprawa

SLA w utrzymaniu aplikacji to umówione czasy, w jakich wykonawca podejmuje zgłoszenie, przywraca możliwość pracy i usuwa przyczynę błędu. Te trzy terminy rozróżniają m.in. wzorcowe klauzule umowy z usługami utrzymania na gov.pl (odczyt 02.11.2026):

• Czas reakcji: moment, w którym ktoś podejmuje zgłoszenie.
• Czas obejścia: moment, w którym ludzie mogą znów pracować, choć przyczyna jeszcze nie jest usunięta.
• Czas naprawy: trwałe usunięcie przyczyny.

Druga liczba to dostępność. Przy miesiącu 30-dniowym (43 200 minut) 99,5% oznacza do 3 h 36 min przestoju, a 99,9% do 43 minut.

Kategorie błędów ustala się w umowie. Jako przykład, nie normę: kancelaria Rubicon (odczyt 02.11.2026) podaje dla błędu krytycznego reakcję w 30–60 minut i naprawę w 4–8 godzin, a dla zwykłej usterki 1 dzień roboczy i 3–5 dni roboczych. Więcej o zapisach w umowie z software house.

Ile kosztuje utrzymanie: model, nie cennik

Ile kosztuje utrzymanie aplikacji, zależy bardziej od modelu rozliczenia i krytyczności aplikacji niż od technologii, więc ceny porównuj dopiero przy tym samym zakresie.

• Abonament na utrzymanie aplikacji: stała kwota za ustalony zakres. Plus: przewidywalność i wykonawca znający system. Minus: płacisz też w spokojne miesiące.
• Pula godzin: godziny do wykorzystania na utrzymanie i drobne zmiany. Plus: elastyczność. Minus: drobne zmiany łatwo „przejadają” godziny przeznaczone na aktualizacje.
• Rozliczenie za zgłoszenia: płacisz, gdy coś zlecasz. Plus: brak stałego kosztu. Minus: nikt nie robi prewencji, a termin nie jest gwarantowany.

Dla orientacji, nie jako średnia rynkowa: w ofertach odczytanych 02.11.2026 Squares zaczyna od 300 zł netto miesięcznie, UDB od 1 500 zł miesięcznie za 5 godzin, a Informatix w tekście z 21.10.2026 podaje od 800 do 6 000 zł netto miesięcznie plus infrastruktura. Porównuj zakres z tabelą powyżej, nie nazwę pakietu.

U mnie opieka techniczna nad aplikacją po wdrożeniu to pakiet App Care od 2 999 zł netto miesięcznie, bez określonego terminu umowy. Obejmuje monitoring oraz aktualizacje serwera, frameworka, języka programowania i bibliotek. Kopie zapasowe z testem odtworzenia i analityka użytkowników to osobne elementy opieki, których zakres i koszt warto ustalić z wykonawcą oddzielnie. Poprawki błędów rozliczane są osobno. Szczegóły w pakietach App Building.

Kiedy można ograniczyć opiekę, a kiedy nie

Opiekę można ograniczyć, gdy aplikacja jest prostym narzędziem bez danych osobowych, bez płatności i bez dostępu z internetu; jeśli przetwarza dane klientów, płatności albo jest kluczowa dla firmy, potrzebuje stałej opieki.

Uczciwie: wewnętrzny kalkulator w sieci firmowej może wystarczyć z przeglądem raz lub dwa razy w roku, co zauważa też ai-gluon w tekście z 12.10.2026. Stała opieka jest potrzebna, gdy aplikacja przetwarza dane osobowe, przyjmuje płatności lub zamówienia, jest dostępna z internetu, ma integracje z innymi systemami albo jej przestój zatrzymuje sprzedaż czy obsługę klienta.

Osobne ryzyko to wiedza w głowie jednej osoby, o czym piszę we wpisie co się stanie, jeśli jutro odejdzie jedyny programista.

A co z prawem? KSC, CRA i PLD w jednym akapicie

KSC, CRA i PLD zwykle nie dotyczą aplikacji MŚP wprost, ale pokazują wspólny kierunek: bezpieczeństwo przez cały cykl życia oprogramowania. Nowelizacja KSC wdrażająca NIS2 obowiązuje od 3.04.2026 i obejmuje podmioty kluczowe i ważne, nie każdą firmę (gov.pl, 10.04.2026). Cyber Resilience Act (2024/2847) dotyczy producentów wprowadzających na rynek produkty z elementami cyfrowymi, z obowiązkiem zgłaszania aktywnie wykorzystywanych podatności od 11.09.2026, a czysty SaaS jest poza jego zakresem (Komisja Europejska, odczyt 02.11.2026). Dyrektywa o produktach wadliwych (2024/2853, termin wdrożenia 9.12.2026) uznaje oprogramowanie za produkt, a brak aktualizacji bezpieczeństwa może być wadą, ale chroni osoby fizyczne, więc w relacji B2B firma nie dostanie z niej odszkodowania za przestój czy utratę danych firmowych.

Stan prawny na 02.11.2026. To nie jest porada prawna; sekcja wymaga przejrzenia przez prawnika.

Od czego zacząć: audyt i plan opieki

Zacznij od przeglądu stanu aplikacji, potem ustal jej krytyczność, a na końcu podpisz umowę opieki z SLA dopasowanym do tej krytyczności.

1. Przegląd stanu aplikacji: wersje, luki, kopie, monitoring, dostępy. Efekt: lista ryzyk z priorytetami.
2. Poziom krytyczności: dane, płatności, dostęp z internetu, skutki przestoju.
3. Umowa opieki z SLA: zakres, trzy czasy, dowody w raporcie, granica między utrzymaniem a rozwojem.

W Ariadnie rozwój i utrzymanie są w jednym modelu współpracy, więc reakcja na problem nie zaczyna się od szukania nowego wykonawcy. BeautyDoc przejąłem po poprzednim wykonawcy: najpierw stabilizacja, potem nowe funkcje oparte na danych o użytkownikach.

Nie wiesz, w jakim stanie jest Twoja aplikacja? Zacznij od audytu kodu. Stałą opiekę prowadzę w ramach rozwoju aplikacji albo pakietu App Care od 2 999 zł netto miesięcznie, bez określonego terminu umowy: monitoring oraz aktualizacje serwera, frameworka, języka programowania i bibliotek. Kopie zapasowe, analitykę i poprawki błędów ustalamy osobno. Wolisz najpierw porozmawiać? Umów rozmowę.

FAQ: utrzymanie aplikacji

Czy aplikację, która działa, można zostawić bez opieki?

Nie bez konsekwencji. Otoczenie aplikacji zmienia się dalej, a znane luki czekają na wykorzystanie. Minimum to aktualizacje bezpieczeństwa, monitoring i sprawdzone kopie. Prostemu narzędziu bez danych osobowych może wystarczyć przegląd raz lub dwa razy w roku.

Co obejmuje utrzymanie aplikacji?

Aktualizacje i poprawki bezpieczeństwa, monitoring, kopie zapasowe z testem odtworzenia, obsługę zgłoszeń według SLA, domeny i certyfikaty, analitykę użycia, raport miesięczny i pulę godzin na drobne zmiany.

Czym różni się utrzymanie od rozwoju aplikacji?

Utrzymanie dba o to, żeby istniejąca aplikacja działała i była bezpieczna. Rozwój dodaje nowe funkcje, moduły i integracje, zwykle z osobnego budżetu. Drobne poprawki mieszczą się w puli godzin. Granicę warto zapisać w umowie.

Ile kosztuje utrzymanie aplikacji?

Zależy od modelu rozliczenia, krytyczności aplikacji i SLA. W ofertach polskich wykonawców odczytanych 02.11.2026 stawki zaczynają się od kilkuset złotych netto miesięcznie i sięgają kilku tysięcy przy krótkich czasach naprawy. Porównuj zakres i dowody, nie samą kwotę.

Co się stanie, jeśli przestanę płacić za utrzymanie?

Zwykle nic od razu. Zatrzymują się aktualizacje, monitoring i gotowość do reakcji, a ryzyka narastają po cichu. Przy awarii albo nowej funkcji najpierw zapłacisz za nadrobienie zaległości.

Czy trzeba aktualizować aplikację, jeśli działa?

Tak, jeśli któryś komponent traci wsparcie lub ma znaną lukę. Według Verizon DBIR z 19.05.2026 wykorzystanie podatności było punktem wejścia w 31% naruszeń. Małe, regularne aktualizacje są tańsze niż jedna duża migracja.

Jak często aktualizować aplikację?

Poprawki bezpieczeństwa na bieżąco, krytyczne poza kolejką. Zależności i framework aktualizuję w swoich projektach 1–2 razy w miesiącu, zależnie od sytuacji. Wersje główne planuj według kalendarza końca wsparcia, z wyprzedzeniem. Rytm zapisz w umowie.

Co to jest SLA i czym różni się czas reakcji od czasu naprawy?

SLA to umówione poziomy usługi. Czas reakcji to moment podjęcia zgłoszenia, czas obejścia to moment, gdy ludzie mogą znów pracować, a czas naprawy to trwałe usunięcie przyczyny. Dostępność 99,5% oznacza do 3 h 36 min przestoju w miesiącu.

Czy kopie zapasowe wystarczą, jeśli nikt ich nie sprawdza?

Nie. Art. 32 RODO wymaga zdolności do szybkiego przywrócenia danych i regularnego testowania zabezpieczeń. W sprawie opisanej przez UODO 27.06.2023 dane odzyskano po prawie trzech miesiącach. Kopię trzeba próbnie odtwarzać i zapisywać czas odtworzenia.

Po co analizować zachowania użytkowników w aplikacji firmowej?

Żeby wiedzieć, które funkcje są używane, gdzie ludzie się gubią i co poprawić albo wyłączyć. Bez danych rozwój jest na wyczucie. W aplikacjach publicznych analityka zwykle wymaga zgody (art. 399 Prawa komunikacji elektronicznej).

Czy aplikacja wewnętrzna na Androida musi spełniać wymagania Google Play?

Nie, jeśli jest trwale prywatna i dystrybuowana tylko w jednej organizacji: Google wyłącza takie aplikacje z wymagań target API. Nadal potrzebuje poprawek bezpieczeństwa. Aktualizacje aplikacji publicznych od 31.08.2026 muszą celować w Android 16 (API 36).

Czy NIS2, CRA albo dyrektywa o produktach wadliwych dotyczy mojej aplikacji?

Zwykle nie wprost. KSC (NIS2) obejmuje podmioty kluczowe i ważne, CRA producentów wprowadzających produkty na rynek, a dyrektywa o produktach wadliwych chroni osoby fizyczne, nie firmy w B2B. Konkretny przypadek oceń z prawnikiem.

Zobacz wersję Markdown →