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

Autor: Michał Molenda  
Data: 2026-11-02 09:36:34

[Oryginalny artykuł](https://michalmolenda.pl/blog/utrzymanie-aplikacji-czy-mozna-ja-zostawic-bez-opieki)

Aplikacja działa, więc po co płacić za utrzymanie? Sprawdź, co obejmuje opieka: aktualizacje, monitoring, backupy, analityka i model kosztów.

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.

| Obszar | Reaktywnie („naprawiamy, gdy się zepsuje”) | Zapobiegawczo (stała opieka) |
|---|---|---|
| Kto decyduje o terminie | awaria albo atakujący | Ty i wykonawca, według planu |
| Przewidywalność kosztu | niska, faktury nagłe i nierówne | wysoka, stała kwota plus planowane prace |
| Przestój | dłuższy, bo trzeba zrozumieć problem i system | krótszy, bo monitoring wykrywa problem, a wykonawca zna system |
| Wiedza o systemie | zanika między awariami | aktualna, razem z dokumentacją |
| Bezpieczeństwo | luki czekają na wykorzystanie | poprawki wchodzą w ustalonym rytmie |
| Dowody dla klienta albo audytora | brak albo odtwarzane z pamięci | raporty, lista aktualizacji, wyniki testów kopii |

### 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](https://michalmolenda.pl/blog/aktualizacja-php-w-firmie-ryzyko-koszt-i-jak-pomaga-ai).

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](https://www.verizon.com/about/news/breach-industry-wide-dbir-finds) 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](https://www.verizon.com/business/resources/Te26/reports/2026-dbir-data-breach-investigations-report.pdf)) 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](https://newsroom.ibm.com/2026-07-29-ibm-study-one-in-four-malicious-breaches-are-ai-enabled,-costing-companies-6-million-on-average) 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.

| Technologia | Co się kończy albo zmienia | Data | Źródło |
|---|---|---|---|
| PHP 8.2 | koniec poprawek bezpieczeństwa (więcej w [artykule o aktualizacji PHP](https://michalmolenda.pl/blog/aktualizacja-php-w-firmie-ryzyko-koszt-i-jak-pomaga-ai)) | 31.12.2026 | [php.net](https://www.php.net/supported-versions.php) |
| Node.js 20 | koniec wsparcia (już minął) | 30.04.2026 | [nodejs/Release](https://github.com/nodejs/Release) |
| Node.js 22 | koniec wsparcia | 30.04.2027 | [nodejs/Release](https://github.com/nodejs/Release) |
| Angular 20 | koniec LTS (data przybliżona według Angulara) | 28.11.2026 | [angular.dev](https://angular.dev/reference/releases) |
| Laravel 12 | koniec poprawek bezpieczeństwa | 24.02.2027 | [laravel.com](https://laravel.com/docs/13.x/releases) |
| Google Play | aktualizacje muszą celować w Android 16 (API 36); istniejące aplikacje poniżej API 35 przestają być dostępne dla nowych użytkowników na nowszych Androidach | od 31.08.2026 (przedłużenia wygasły 01.11.2026) | [Google Play Console Help](https://support.google.com/googleplay/android-developer/answer/11926878) |
| Apple App Store | aplikacje muszą być budowane w Xcode 26+ z SDK iOS 26 | od 28.04.2026 | [Apple Developer](https://developer.apple.com/news/upcoming-requirements/) |

Aplikacja niespełniająca wymagań Google nie znika z Google Play: według [Google](https://support.google.com/googleplay/android-developer/answer/11926878) (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](https://michalmolenda.pl/uslugi/aplikacje-mobilne).

## 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:

| Obszar | Co się robi | Jak często | Co widzi właściciel (dowód) | Co grozi bez tego |
|---|---|---|---|---|
| Aktualizacje zależności i frameworka | aktualizacja i testy | 1–2 razy w miesiącu, zależnie od sytuacji; wersje główne według kalendarza wsparcia | lista komponentów z wersjami | jedna duża, ryzykowna migracja |
| Poprawki bezpieczeństwa | śledzenie luk, wdrażanie łatek | na bieżąco, krytyczne poza kolejką | opis luki i data poprawki | wykorzystanie znanej luki |
| Monitoring dostępności i błędów | alerty o niedostępności i błędach | stale | zestawienie dostępności i alertów | o awarii mówi Ci klient |
| Kopie zapasowe z testem odtworzenia | kopie poza serwerem, próbne odtworzenie | kopie np. codziennie, test np. co kwartał | wynik i czas ostatniego testu | kopia zawodzi w dniu awarii |
| Obsługa zgłoszeń według SLA | przyjęcie, klasyfikacja, naprawa | według umowy | zgłoszenia z czasami reakcji i naprawy | czekanie na wolny termin |
| Domeny, certyfikaty i konta w sklepach | pilnowanie odnowień i wymagań sklepów | kalendarz terminów | lista terminów i właścicieli kont | wygasła domena, zablokowana publikacja |
| Analityka użycia | dane o użyciu i wnioski | stale; omówienie np. co kwartał | podsumowanie z wnioskami | rozwój na wyczucie |
| Raport miesięczny | prace, incydenty, ryzyka, rekomendacje | co miesiąc | jeden dokument | nie wiesz, za co płacisz |
| Pula godzin na drobne zmiany | małe poprawki bez osobnej wyceny | według potrzeb | zestawienie godzin | każda drobnostka czeka na wycenę |
| Przegląd długu i dokumentacji | lista miejsc do poprawy, dokumentacja | np. co kwartał | lista ryzyk z priorytetami | wiedza tylko w głowach |
| Dostęp i wiedza | konta na firmę, druga osoba znająca system | np. co pół roku | lista dostępów i osób | zależność od jednej osoby |

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](https://www.verizon.com/about/news/breach-industry-wide-dbir-finds) 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](https://github.com/php/php-src/security/advisories/GHSA-fpwc-w8rq-cr92), czyli wyciek danych uwierzytelniających do innej domeny przy przekierowaniach w obsłudze adresów HTTP ([ChangeLog PHP](https://www.php.net/ChangeLog-8.php)).
- **Laravel:** 23.10.2026 opublikowano krytyczną podatność [CVE-2026-114509](https://github.com/advisories/GHSA-f9x3-7vq9-cph6) 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](https://security-tracker.debian.org/tracker/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](https://michalmolenda.pl/uslugi/rozwoj-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](https://michalmolenda.pl/blog/jak-kontrolowac-software-house-nie-majac-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](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679) (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](https://uodo.gov.pl/pl/138/2764): 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](https://michalmolenda.pl/blog/odpowiedzialnosc-za-kod-ai-kto-sie-pod-nim-podpisze).

*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](https://michalmolenda.pl/case-studies/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](https://cik.uke.gov.pl/gfx/cik/userfiles/_public/ustawa_prawo_komunikacji_elektronicznej_z_12_lipca_2024_r.pdf) (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](https://www.gov.pl/documents/31305/436699/Wzorcowe+klauzule+-+umowa+wdro%C5%BCeniowa+z+us%C5%82ugami+utrzymania.pdf/ee27ba82-5b9c-c5fd-ce2e-ad15406c510a) (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](https://rubiconlegal.pl/umowa-sla-czym-jest-service-level-agreement-i-co-powinna-zawierac/) (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](https://michalmolenda.pl/blog/umowa-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](https://squares.pl/uslugi/opieka-sla/) zaczyna od 300 zł netto miesięcznie, [UDB](https://udb.pl/pl/uslugi/utrzymanie-aplikacji/) od 1 500 zł miesięcznie za 5 godzin, a [Informatix](https://informatix.com.pl/blog/koszt-utrzymania-aplikacji-webowej) 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](https://michalmolenda.pl/uslugi/app-building#pakiety).

## 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](https://ai-gluon.com/blog/koszt-utrzymania-aplikacji/) 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](https://michalmolenda.pl/blog/co-sie-stanie-jesli-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](https://www.gov.pl/web/baza-wiedzy/nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-ksc---najwazniejsze-terminy)). 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](https://digital-strategy.ec.europa.eu/pl/policies/cra-reporting)). Dyrektywa o produktach wadliwych ([2024/2853](https://eur-lex.europa.eu/eli/dir/2024/2853/oj), 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](https://michalmolenda.pl/case-studies/ariadna) rozwój i utrzymanie są w jednym modelu współpracy, więc reakcja na problem nie zaczyna się od szukania nowego wykonawcy. [BeautyDoc](https://michalmolenda.pl/case-studies/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](https://michalmolenda.pl/uslugi/audyt-kodu). Stałą opiekę prowadzę w ramach [rozwoju aplikacji](https://michalmolenda.pl/uslugi/rozwoj-aplikacji) albo pakietu [App Care](https://michalmolenda.pl/uslugi/app-building#pakiety) 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ę](https://michalmolenda.pl/kontakt).

## 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.