Nie ma jednej uczciwej miesięcznej ceny utrzymania aplikacji bez określenia, kto i za co odpowiada. Koszt zależy od stanu systemu, technologii, infrastruktury, liczby ważnych procesów i integracji, potrzebnego monitoringu, sposobu wykonywania kopii i wdrożeń, liczby zgłoszeń oraz oczekiwanych godzin reakcji.
Najlepiej rozdzielić cztery grupy wydatków: infrastrukturę i usługi zewnętrzne, stałą gotowość zespołu, faktycznie wykonywane prace oraz większy rozwój. Dopiero wtedy można porównać dwie oferty i sprawdzić, czy dotyczą tego samego zakresu.
Hosting to tylko jedna część kosztu
Serwer, domena i certyfikat umożliwiają działanie aplikacji, ale same jej nie utrzymują. Hosting nie sprawdzi automatycznie, czy zadanie wysyłające faktury przestało działać, integracja nie pobrała zamówień albo kopia bazy nie nadaje się do odtworzenia. Nie zaktualizuje też kodu i nie naprawi błędu po zmianie zewnętrznego API, jeśli taka usługa nie została osobno uzgodniona.
Podobnie jest z kopią zapasową. Informacja, że plik powstał, nie potwierdza jeszcze, że obejmuje wszystkie potrzebne dane i da się go poprawnie odtworzyć. Zakres kopii, częstotliwość, okres przechowywania, miejsce zapisu i sposób testowania powinny być opisane w ofercie.
Z czego składa się koszt utrzymania aplikacji?
| Grupa kosztów | Co może obejmować | Za co rzeczywiście płaci firma |
|---|---|---|
| Infrastruktura i usługi zewnętrzne | serwer lub chmurę, domenę, pocztę, SMS, płatności, przechowywanie plików, monitoring i zewnętrzne API | za zasoby oraz dostęp do usług potrzebnych aplikacji |
| Stała opieka i gotowość | odbieranie alertów i zgłoszeń, kontrolę kopii, planowanie aktualizacji i odpowiedzialność w określonych godzinach | za dostępność osoby znającej uzgodniony zakres i zdolnej rozpocząć obsługę problemu |
| Prace wykonywane w systemie | diagnozy, naprawy, aktualizacje, wdrożenia, konfigurację i niewielkie zmiany | za konkretną pracę mieszczącą się w abonamencie, limicie albo osobnym zleceniu |
| Większy rozwój | nowe moduły, migracje, modernizację, przebudowę infrastruktury lub odzyskiwanie po poważnym incydencie | za osobny projekt, którego nie należy ukrywać w ogólnym haśle „utrzymanie” |
Jedna oferta może obejmować wyłącznie serwer i reakcję na zgłoszenie. Inna może dodatkowo zawierać monitoring ważnych procesów, kontrolę kopii, regularne aktualizacje oraz ustalony limit prac. Porównanie samych kwot bez rozpisania odpowiedzialności prowadzi więc do błędnych wniosków.
Co najbardziej wpływa na wycenę?
Znaczenie systemu dla firmy
Inaczej utrzymuje się stronę informacyjną, a inaczej system przyjmujący zamówienia, rezerwacje lub dane potrzebne pracownikom przez cały dzień. Im większe skutki zatrzymania procesu, tym ważniejsze stają się monitoring, jasny kanał zgłoszeń i wcześniej uzgodniony sposób reakcji.
Stan kodu i technologii
Koszt rośnie, gdy projekt używa niewspieranych wersji PHP, frameworka lub bibliotek, nie ma testów albo wymaga ręcznego wdrażania bez bezpiecznej drogi powrotu. PHP publikuje daty aktywnego i krytycznego wsparcia dla każdej gałęzi, a Laravel ma własną politykę poprawek i aktualizacji bezpieczeństwa. Oznacza to, że wersje technologii trzeba kontrolować w całym okresie działania aplikacji, nie tylko w dniu jej uruchomienia.
Liczba procesów i integracji
Sprawdzenie samej strony głównej nie wykryje wszystkich problemów. Osobnego nadzoru mogą wymagać kolejki, zadania cykliczne, płatności, wysyłka wiadomości, importy, eksporty i połączenia z innymi systemami. Każdy dodatkowy proces tworzy własne sytuacje błędne oraz zależność od zewnętrznego dostawcy.
Jakość materiałów i dostępów
Repozytorium, opis infrastruktury, lista usług, procedura wdrożenia i dane o kopiach skracają rozpoznanie. Jeżeli poprzedni wykonawca nie przekazał tych informacji, pierwszym etapem może być uporządkowanie dostępu i sprawdzenie stanu systemu. Pomaga w tym checklista przejęcia aplikacji, ale sama checklista nie zastępuje diagnozy kodu ani serwera.
Oczekiwane godziny i czas reakcji
Gotowość ma koszt nawet w miesiącu bez awarii. Krótszy czas pierwszej reakcji wymaga zarezerwowania dostępności i znajomości konkretnego systemu. Trzeba też rozróżnić rozpoczęcie obsługi od zakończenia naprawy. Termin rozwiązania problemu często można określić dopiero po diagnozie.
Kiedy wystarczy jednorazowa praca?
Stały abonament nie jest potrzebny każdej aplikacji. Jednorazowe zlecenie może wystarczyć, gdy system nie obsługuje krytycznego procesu, firma akceptuje planowany termin prac i potrzebuje konkretnej aktualizacji, konfiguracji albo naprawy. Pozostałe obowiązki, takie jak monitoring, kopie i kontakt z hostingiem, muszą wtedy mieć innego właściciela.
Stała opieka ma większy sens, gdy aplikacja jest używana codziennie, regularnie się zmienia, ma integracje albo zadania działające w tle. Jest również przydatna, gdy firma chce przypisać jednej stronie odpowiedzialność za alerty, kopie, plan aktualizacji i kontrolowane wdrożenia.
W Domin Software możemy ustalić prace doraźne, regularną opiekę albo osobno wyceniony wariant z czasem reakcji. Dokładny model zależy od systemu i skutków jego niedostępności.
Dlaczego SLA wpływa na koszt?
SLA nie powinno być ogólną obietnicą szybkiej pomocy. Musi wskazywać aplikacje i środowiska objęte umową, dni oraz godziny obsługi, kanały zgłoszeń, poziomy ważności, czas pierwszej reakcji i obowiązki obu stron.
Domin Software nie publikuje jednego SLA dla wszystkich klientów ani obietnicy obsługi 24/7. Standardowo obsługujemy zgłoszenia od niedzieli do piątku, od 8:00 do 17:00 czasu Europe/Warsaw. W soboty nie świadczymy obsługi. W polskie dni ustawowo wolne możemy reagować wyłącznie na wcześniej uzgodnione zdarzenia krytyczne. Dokładne warunki zaczynają obowiązywać dopiero po zapisaniu ich w ofercie lub umowie.
Monitoring działający przez całą dobę nie oznacza automatycznie całodobowej reakcji człowieka. Może wykryć problem i zapisać alert, ale termin jego obsługi zależy od uzgodnionego dyżuru.
Jak porównać dwie oferty utrzymania?
| Pytanie | Co powinno być jasno zapisane |
|---|---|
| Co dokładnie jest objęte? | aplikacje, środowiska, serwer, integracje i ważne procesy |
| Co jest monitorowane? | konkretne adresy, zadania, kolejki, integracje oraz odbiorcy alertów |
| Jak sprawdzane są kopie? | zakres, częstotliwość, okres przechowywania, lokalizacja i test odtworzenia |
| Kiedy obsługiwane są zgłoszenia? | dni, godziny, strefa czasowa, kanały i zasady eskalacji |
| Co oznacza czas reakcji? | potwierdzenie zgłoszenia, wstępną ocenę i rozpoczęcie obsługi, a nie automatycznie zakończenie naprawy |
| Jak wykonywane są zmiany? | testy, akceptację, wdrożenie i możliwość wycofania |
| Co mieści się w opłacie stałej? | gotowość, nazwane obowiązki i ewentualny limit prac |
| Co jest płatne osobno? | większy rozwój, migracje, audyty, odzyskiwanie po ataku i prace ponad zakres |
| Kto jest właścicielem kont? | klient powinien zachować kontrolę nad hostingiem, domeną, danymi i rozliczeniami |
Jeżeli w jednej ofercie nie ma tych informacji, warto je uzupełnić przed porównaniem ceny. Najtańsza kwota może oznaczać najmniejszy zakres odpowiedzialności, ale wyższa cena również nie dowodzi automatycznie lepszej ochrony. Decyduje zapisany zakres i sposób sprawdzenia wykonania usługi.
Co przygotować do wyceny opieki?
Na początku wystarczy opis zastosowania aplikacji i najważniejszych procesów. Przydatne będą także:
- technologia i wersje, jeżeli są znane;
- lista środowisk, integracji, zadań w tle i usług zewnętrznych;
- informacja o repozytorium, dokumentacji, testach i sposobie wdrażania;
- obecny zakres monitoringu i kopii;
- skutek awarii oraz akceptowane godziny obsługi;
- typowe zgłoszenia i oczekiwany zakres niewielkich zmian;
- informacja, kto jest właścicielem kont i kto zatwierdza wdrożenia.
Do formularza nie należy przesyłać haseł, kluczy, baz danych ani danych klientów. Na pierwszym etapie potrzebujemy opisu sytuacji, nie dostępu do produkcji.
Planer utrzymania aplikacji pomoże zebrać te informacje i utworzyć robocze podsumowanie. Wynik nie jest automatyczną wyceną ani umową SLA.
Co pokazują nasze wcześniejsze projekty?
W systemie 44Islands rozwój nie zakończył się po pierwszym wdrożeniu. Kolejne etapy rozszerzały obsługę rezerwacji, role użytkowników i sprzedaż bezpośrednią. Ten przykład pokazuje, że utrzymanie działającej aplikacji może obejmować zarówno opiekę nad obecnym zakresem, jak i oddzielnie uzgadniany rozwój.
Historyczna opieka nad trzema sklepami PrestaShop 1.6 obejmowała między innymi konfigurację VPS, środowiska, domen, Apache i PHP, instalację modułów oraz poprawki wydajności i szablonów. Trwała około roku. Projekty nie działają już produkcyjnie, dlatego ten materiał potwierdza rodzaj wykonywanych prac, a nie obecny stan sklepów ani koszt nowej usługi.
W obu przypadkach zakres wynikał z konkretnego systemu. Nie traktujemy wcześniejszych realizacji jako gotowego cennika dla kolejnego klienta.
Najczęstsze pytania
Czy koszt hostingu obejmuje utrzymanie aplikacji?
Nie, chyba że oferta wyraźnie łączy obie usługi i opisuje odpowiedzialność. Hosting zapewnia zasoby, natomiast utrzymanie może obejmować monitoring procesów, kopie, aktualizacje, diagnozy, wdrożenia i obsługę zgłoszeń.
Czy stała opieka zawsze zawiera określoną liczbę godzin programisty?
Nie musi. Opłata może obejmować gotowość i konkretne obowiązki albo dodatkowo limit prac. Umowa powinna wskazywać, co dzieje się po wykorzystaniu limitu i które zadania są osobnym projektem.
Czy wykonanie kopii wystarcza do zabezpieczenia systemu?
Nie. Trzeba jeszcze wiedzieć, co obejmuje kopia, gdzie jest przechowywana, jak długo i czy można z niej odtworzyć działający system. Test odtworzenia powinien mieć uzgodniony zakres oraz częstotliwość.
Czy można ustalić koszt bez dostępu do kodu?
Można wstępnie określić model współpracy i informacje potrzebne do wyceny. Dokładna odpowiedzialność za istniejący system może jednak wymagać płatnego rozpoznania kodu, infrastruktury, wersji i sposobu wdrażania.
Czy monitoring oznacza reakcję 24/7?
Nie. Monitoring może działać stale, ale obsługa alertu odbywa się w godzinach zapisanych w umowie. Dyżur poza standardowymi godzinami wymaga osobnego uzgodnienia.
Czy rozwój nowych funkcji mieści się w utrzymaniu?
Niewielkie zmiany mogą mieścić się w ustalonym limicie. Większe moduły, migracje i modernizacja powinny mieć osobny zakres, kryteria odbioru i wycenę.
Wybierz następny krok
Jeżeli chcesz najpierw uporządkować potrzeby, użyj planera utrzymania aplikacji. Zbiera informacje o systemie, kopiach, monitoringu, zgłoszeniach i oczekiwanym modelu współpracy, ale nie wysyła automatycznie danych i nie tworzy wyceny.
Jeżeli zakres jest już znany, sprawdź stałą opiekę nad aplikacjami i sklepami. Opisz zastosowanie systemu, najważniejsze procesy, skutek awarii i oczekiwane godziny obsługi. Na tej podstawie ustalimy, czy wystarczy jednorazowe zlecenie, regularna opieka czy osobno uzgodniony wariant SLA.
Źródła
- PHP Supported Versions, dostęp sprawdzony 28.10.2026.
- Laravel Release Notes and Support Policy, dostęp sprawdzony 28.10.2026.
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, dostęp sprawdzony 28.10.2026.
- OWASP A06:2021, Vulnerable and Outdated Components, dostęp sprawdzony 28.10.2026.