Ten schemat jest mi dobrze znany: comiesięczna „opieka techniczna” nad czterostronicową wizytówką. Zbyt często to faktura za brak jakiejkolwiek pracy.
Widziałem to u agencji i freelancerów w dziesiątkach wycen. Ktoś stawia stronę na WordPressie, oddaje ją klientowi i dokleja abonament. Na liście obietnic są aktualizacje silnika i wtyczek, kopie w chmurze i monitoring bezpieczeństwa. Potem przez miesiące nikt nie wchodzi do panelu. Aktualizacje idą automatycznie na hostingu albo ktoś raz na kwartał klika „Aktualizuj wszystko” – oczywiście bez żadnych testów. Gdy coś pada, zwykle pierwszy zauważa to właściciel strony.
Ten schemat działania zamienia podstawową higienę oprogramowania w stały podatek nakładany na nietechnicznego przedsiębiorcę i nie daje w zamian realnego bezpieczeństwa.
Nie twierdzę też, że każda opieka to zbędny koszt. Gdy system przyjmuje płatności, synchronizuje magazyn z ERP, rozlicza subskrypcje albo jest głównym lejkiem sprzedaży, potrzebna jest prawdziwa opieka operacyjna. Przestój w takim wypadku bezpośrednio niszczy przychód.
To, za co biorę pieniądze, zależy od architektury i ryzyka. Oddzielam automatyczne aktualizacje od odpowiedzialności operacyjnej. To dwa zupełnie różne typy pracy.
Dlaczego nie sprzedaję comiesięcznego abonamentu na aktualizacje
Zwykła strona informacyjna nie potrzebuje wielu godzin ręcznej pracy programisty co miesiąc.
Nowoczesny hosting i CMS ogarniają drobne aktualizacje same. WordPress od lat robi aktualizacje silnika w tle, a część zarządzanych hostingów i płatnych dodatków testuje wtyczki najpierw na kopii strony, ze sprawdzeniem regresji wizualnej. Jeśli strona jest w pełni statyczna i nie używa funkcji serverless – pisałem o tym w Astro + AI vs WordPress dla prostych stron contentowych – serwerowa powierzchnia ataku niemal znika. Statyczny serwis na Cloudflare Pages nie ma bazy do łatania, brak ryzyka związanego z lukami w PHP oraz wtyczkami, które trzeba stale monitorować i aktualizować.
Automatyzacja nie niweluje całej pracy. Dla prostej strony na WordPressie rezerwuję zwykle godzinę miesięcznie, czasem dwie albo trzy: przegląd i aktualizację głównych wtyczek, które wymagają decyzji, a nie kliknięcia; sprawdzenie, czy hosting nie wygasza używanej wersji PHP; test, czy formularz kontaktowy nadal dostarcza pocztę; rzut oka na log aktualizacji. Panel administracyjny zarządzający wieloma stronami skraca ten czas. Nie usuwa go.
Nie wyceniam tej godziny jako pełnego pakietu monitoringu i nie sprzedaję klikania „Aktualizuj wszystko” jako monitoringu bezpieczeństwa. To opłata za wygodę w kostiumie polisy.
Gorzej: klikanie aktualizacji bez testów E2E nie chroni przed awarią. W niesprawdzanym abonamencie łatki wgrywane są na ślepo. Jeśli konflikt wtyczek zepsuje formularz albo układ na telefonie, strona stoi zepsuta, aż ktoś to zgłosi. Jeśli klient płaci mi za opiekę, a i tak sam musi być testerem, to ja nie wykonałem swojej pracy.
Gdy strona rzadko się zmienia, nie przyjmuje płatności i jest informacyjna, moim zdaniem ryczałt powinien odpowiadać czasowi przeglądu, a nie pełnemu pakietowi operacyjnemu. Moja odpowiedź architektoniczna: uprościć stack, włączyć automatyczne backupy i aktualizacje, a czas programisty rozliczać wtedy, gdy naprawdę jest co zmieniać.
Opiekę biorę tam, gdzie awaria kosztuje pieniądze
Opieka staje się obowiązkowa w chwili, gdy przestój, zepsute dane albo zablokowany proces niszczą przychód.
Weźmy sklep WooCommerce z cennikami B2B, importem magazynu i webhookami płatności, taki jak w WooCommerce B2B: wiele wtyczek czy własna integracja. Tam aktualizacja nigdy nie jest „tylko aktualizacją”.
Drobna zmiana we wtyczce bramki płatności może zmienić payload webhooka, więc zamówienia zostają w statusie „Oczekuje na płatność”, a pieniądze już schodzą z kont klientów. Nowa wersja WooCommerce może wycofać filtr używany przez integrację z magazynem i po cichu zatrzymać stany. Niezindeksowane zapytanie z dodatku potrafi przy większym ruchu nasycić bazę albo wywołać kolizje blokad.
W systemie transakcyjnym opiekę traktuję jako cztery warstwy:
1. Ciągłość procesów biznesowych
To, że strona główna zwraca HTTP 200, nic mi nie mówi. Chcę wiedzieć, czy kluczowe ścieżki dochodzą do końca:
- Czy testowe zamówienia przechodzą przez wszystkie aktywne bramki płatności?
- Czy maile transakcyjne przechodzą SPF/DKIM i trafiają do skrzynek?
- Czy nocny import stanów z ERP przetworzył cały plik, bez pominiętych produktów?
- Czy kolejki w Action Scheduler idą na czas i nie kręcą się w błędach?
2. Staging przed produkcją
Produkcja nie jest poligonem. Każda aktualizacja bibliotek i wtyczek idzie najpierw na staging, przez testy koszyka i zamówienia, i dopiero potem na żywy serwer produkcyjny.
3. Audyt logów i wczesne anomalie
Poważne błędy rzadko zaczynają się od awarii serwera. Zaczynają się od ostrzeżeń PHP zapełniających dysk, limitów w zewnętrznym API albo coraz wolniejszych zapytań SQL. Warto czytać logi błędów i wolnych zapytań (slow query logs), zanim mały problem stanie się awarią, którą zobaczy klient.
4. Gwarancja odzyskania (RTO i RPO)
Kopia zapasowa ma wartość dopiero wtedy, gdy ktoś sprawdził, że da się z niej wrócić. Prawdziwa opieka to próbne przywracanie bazy i plików: czy po awarii system wraca do znanego stanu w umówionym czasie?
Przy sklepie albo aplikacji sprzedaję redukcję ryzyka i gwarantowaną gotowość, nie same aktualizacje wtyczek.
Trzy modele, których używam przy opiece nad stroną
Pracę układam w jednym z trzech modeli. Wszystko bardziej mgliste kończy się abonamentem za klikanie przycisków.
| Model opieki | Dla kogo | Za co faktycznie płacisz | Typowa struktura rozliczeń |
|---|---|---|---|
| Architektura zero-maintenance | Strony wizytówkowe, landing page, proste blogi | Projekt eliminujący podatności (SSG/Astro), brak stałych prac technicznych | 0 zł/mies. za utrzymanie (rozliczenie per zadanie) |
| Automatyczna higiena + wsparcie doraźne | Standardowe strony firmowe z blogiem i formularzami | Automatyczne backupy, monitoring uptime, miesięczny przegląd, pakiet godzin w razie potrzeby | Niski ryczałt lub czyste rozliczenie godzinowe |
| Pełne wsparcie operacyjne i SLA | E-commerce, platformy B2B, dedykowane integracje | Aktywny monitoring procesów, testy na stagingu, audyt logów, gwarantowany czas reakcji | Stały abonament SLA zależnie od skali |
Model 1: Architektura zero-maintenance
Jeśli strona ma potwierdzić, że firma istnieje, odpowiadać na powtarzalne pytania i zbierać zapytania – ten test opisałem w Czy Twoja firma jest gotowa na stronę: praktyczny test – wolę stack, który nie wymaga comiesięcznego łatania.
Astro, Pages CMS albo statyczny HTML na hostingu brzegowym (edge): nie ma bazy do patchowania, PHP do podbijania ani wtyczek do zarządzania. Stałe utrzymanie oprogramowania to 0 zł miesięcznie. Hosting i domena dalej kosztują. Gdy trzeba zmienić treść albo dodać sekcję, rozliczam konkretne zadanie.
Model 2: Automatyczna higiena ze wsparciem na żądanie
Dla WordPressa, który potrzebuje dynamicznego zaplecza, bo treści zmieniają się często, nie biorę pieniędzy za ręczne klikanie aktualizacji.
Setup: zarządzany hosting WordPressa, automatyczne backupy, automatyczne łatki, zewnętrzny monitoring dostępności (UptimeRobot albo Better Stack). Biorę mały ryczałt za miesięczny przegląd higieny. Konflikty wtyczek, nowe funkcje i reszta prac idą na uzgodnionej stawce godzinowej, z określonym oknem reakcji.
Model 3: Umowa SLA i aktywne utrzymanie procesów
Przy sklepach, panelach B2B i narzędziach, których firma nie może mieć wyłączonych, wysoki abonament jest uzasadniony. Nie będę udawał, że jest inaczej.
W kontrakcie muszą być twarde zapisy:
- Gwarantowany czas reakcji (SLA): awarie blokujące sprzedaż w 1–2 godziny, reszta w ciągu 1 dnia roboczego.
- Wdrożenia przez staging: żadnych zmian bezpośrednio na produkcji.
- Syntetyczny monitoring transakcji: zaplanowane zamówienia sandbox albo niskokwotowe, anulowane autoryzacje, żeby wiedzieć, że bramki płatności działają.
- Dedykowany czas programisty: pula godzin w miesiącu na szybkość, indeksowanie bazy i refaktoryzację zależności.
Cztery pytania, na które chcę odpowiedzi przed podpisaniem umowy
Zanim sam wejdę w stałą umowę opieki albo zanim klient podpisze ją z kimś innym, chcę czterech odpowiedzi:
-
„Co dokładnie dzieje się w miesiącu, w którym nic się nie popsuło?” Jeśli jedyna odpowiedź to „dbamy o aktualność wtyczek”, płacisz za skrypt. Jeśli w ofercie są audyt logów, testy na stagingu, przegląd wydajności albo godziny, które przechodzą na kolejny miesiąc, abonament ma treść.
-
„Jak sprawdzacie, że po aktualizacji kluczowe funkcje nadal działają?” Jeśli weryfikacja to wejście na stronę główną, ścieżki konwersji są niechronione. Przy serwisie transakcyjnym chcę automatycznych testów albo spisanej checklisty: formularze, koszyk, logowanie.
-
„Jaki jest gwarantowany czas reakcji, jeśli serwis padnie w weekend?” Umowa bez SLA to nie usługa awaryjna. Jeśli odpowiedź brzmi „postaramy się w poniedziałek”, nie ma powodu płacić za to wysokiego ryczałtu.
-
„Czy tę stronę da się zaprojektować tak, żeby comiesięczna opieka nie była potrzebna?” Przy zwykłej stronie informacyjnej rzetelny partner pokaże opcję statyczną albo headless, która zdejmuje cykl łatek, zamiast z marszu proponować CMS wymagający ciągłego nadzoru.
Biorę pieniądze za pracę, która chroni przychód: monitoring kluczowych procesów, testy aktualizacji na stagingu i gwarantowaną reakcję, gdy mimo wszystko coś się popsuje. Nie biorę za klikanie przycisków, które oprogramowanie obsługuje samo.