19 zgłoszeń zależności miesięcznie i jedna data EOL. Tyle kosztuje utrzymanie, zanim klient o coś poprosi

Zajrzyj do repozytorium strony, którą oddałeś w czerwcu i której od tamtej pory nikt nie dotykał. W zakładce pull requestów nie zobaczysz całej zaległości, tylko pięć pozycji: domyślny limit otwartych pull requestów z aktualizacjami wersji to 5, a kolejne Dependabot wstrzymuje, dopóki tych pięciu ktoś nie scali albo nie zamknie. Zaległość jest większa niż lista, na którą patrzysz, i rośnie niezależnie od tego, czy klient cokolwiek zgłosił.

To jest realna podstawa wyceny utrzymania. Nie procent od wartości projektu, nie stawka, którą ktoś podał na grupie. Liczba zdarzeń miesięcznie razy czas na jedno zdarzenie, plus pozycje z kalendarza, którego nie ustalasz.

Trzy strumienie pracy, które przychodzą bez zgłoszenia klienta

Pierwszy to podatności w zależnościach. W 2025 r. do GitHub Advisory Database trafiło 4101 zweryfikowanych ostrzeżeń, z czego 14,92 proc. dotyczyło ekosystemu npm, czyli około sześciuset pozycji rocznie w jednym tylko menedżerze pakietów. Osobno liczone są ostrzeżenia o złośliwych paczkach: tych opublikowano 7197, o 69 proc. więcej niż rok wcześniej. Twojego projektu dotyczy ułamek z tego, ale ten ułamek przychodzi bez uprzedzenia i ma własny limit: pull requesty z aktualizacjami bezpieczeństwa mają sztywny limit 10 i nie podlegają ustawieniu open-pull-requests-limit.

Drugi strumień to zwykłe aktualizacje wersji. Ich tempo da się regulować, co jest ważne przy wycenie, bo zmienia liczbę zdarzeń w miesiącu. Trzy ustawienia robią większość roboty: schedule.interval (dopuszczalne wartości to daily, weekly, monthly, quarterly, semiannually, yearly albo cron), groups ze wzorcami nazw, które sklejają kilka aktualizacji w jeden pull request, oraz cooldown — domyślnie 3 dni zwłoki od wydania paczki, z osobnymi progami semver-major-days, semver-minor-days i semver-patch-days. Zwłoka nie dotyczy aktualizacji bezpieczeństwa, więc nie da się nią przesunąć strumienia pierwszego.

Trzeci strumień to końce wsparcia środowiska uruchomieniowego. Ten nie negocjuje się z nikim i ma daty znane na lata naprzód — wrócę do nich w osobnej sekcji, bo to one decydują, czy abonament w ogóle się domyka.

Policz zgłoszenia z repozytorium, zanim wpiszesz stawkę

Zamiast przyjmować średnią z cudzego projektu, policz historię własnego. Dla repozytorium na GitHubie liczba pull requestów od Dependabota za ostatni kwartał to jedno polecenie:

gh pr list --repo <wlasciciel/repo> --author "app/dependabot" \
  --state all --limit 300 \
  --json number,title,createdAt,mergedAt \
  --jq '[.[] | select(.createdAt >= "2026-07-01")] | length'

Podziel wynik przez trzy i masz liczbę zdarzeń na miesiąc dla tego konkretnego projektu. Drugie polecenie pokazuje, ile z nich będzie kosztować więcej niż scalenie, bo rozbija zaległość na poziomy wersji:

npm outdated --json | jq -r '
  to_entries[] | [.key, .value.current, .value.latest] | @tsv'

Porównaj pierwszy segment numeru wersji w kolumnie drugiej i trzeciej. Każda pozycja, w której różni się major, to nie aktualizacja, a mała migracja — i jeśli wrzucisz ją do abonamentu bez wyliczenia, to ona zje marżę. Przy stronach na WordPressie odpowiednikiem tego pomiaru jest lista wtyczek z aktywnym wsparciem i ich cyklem wydań; mechanika rachunku jest ta sama.

Minuty na jedno zgłoszenie: cztery klasy zmian

Liczba zdarzeń bez czasu jednostkowego nic nie wnosi. Czas trzeba zmierzyć u siebie, na własnym stacku i własnym CI, bo zależy od tego, co masz zautomatyzowane. Poniższa tabela to szkielet do podstawienia własnych wartości, nie zestawienie branżowe — trzecia kolumna pokazuje rozrzut, jaki daje różnica między projektem z testami e2e i bez nich.

Zmierz po pięć zdarzeń z każdej klasy i zapisz czas w tym samym narzędziu, w którym rozliczasz projekty. Jeśli utrzymanie ma być powtarzalne, ten pomiar jest jednocześnie pierwszym krokiem do spisania procedury — a przy wyborze, co opisać najpierw, pomaga kolejność porządkowania procesów w firmie usługowej. Trzy klasy pierwsze są przewidywalne i wchodzą do abonamentu. Czwarta ma rozkład, którego nie uśrednisz, dlatego w ofercie nie powinna występować jako „obsługa incydentów w ramach abonamentu”, tylko jako czas reakcji z osobno płatną pracą.

Kalendarz EOL, którego nie negocjujesz z klientem

Najdroższe pozycje utrzymania mają daty wpisane w publiczne harmonogramy i nie zależą od tego, jak napisano kod. Te dwie listy wystarczają, by zaplanować budżet na dwa lata naprzód dla większości stron oddawanych dziś w Polsce.

Te daty wchodzą do rachunku jako jedna dwunasta rocznego budżetu na migracje, doliczana do każdego miesiąca. Abonament, który ich nie zawiera, nie jest tańszy — po prostu przenosi rozmowę o pieniądzach na moment, w którym strona klienta stoi na niewspieranym środowisku i zrobiło się pilne.

Kod z modelu nie zmniejsza powierzchni utrzymania

Przy wycenie projektu przyspieszenie z modelu widać od razu: komponent, który zajmował pół dnia, jest po dwudziestu minutach. Przy wycenie utrzymania to przyspieszenie nie ma znaczenia, bo abonament nie płaci za pisanie kodu, a za powierzchnię, którą trzeba pilnować. Powierzchnię opisują trzy liczby, wszystkie do policzenia w minutę:

• Liczba zależności bezpośrednich: jq '.dependencies | length' package.json. Generator dorzuca bibliotekę do jednego komponentu równie chętnie jak do dziesięciu, a każda z nich to pozycja w strumieniu aktualizacji na kolejne lata.
• Liczba miejsc, w których żyje ta sama logika. Jeśli funkcja formatująca cenę jest w siedmiu plikach, to każda zmiana wymagań jest siedmioma zmianami, a trzy z nich ktoś przeoczy.
• Liczba ścieżek bez testu. Przy kodzie pisanym szybko to zwykle te same ścieżki, które najtrudniej sprawdzić klikaniem: płatność, logowanie, formularz z załącznikiem.

Dwie strony o identycznym zakresie funkcjonalnym mogą mieć dwukrotnie różną powierzchnię, i to ta różnica, nie liczba godzin w projekcie, ma być widoczna w stawce miesięcznej. Policz te trzy liczby przed wysłaniem oferty utrzymaniowej, a nie po pierwszym kwartale.

Co musi być w ofercie abonamentowej, a co poza nią

Rachunek bez zapisów w umowie nie obroni się w trzecim miesiącu, bo abonament ma naturalną tendencję do zamieniania się w ryczałt na wszystko. Minimalny zakres, który rozstrzyga spory, zanim się zaczną:

• Co wchodzi: aktualizacje zależności w klasach pierwszej do trzeciej, kopie zapasowe i ich odtworzenie testowe, monitoring dostępności, poprawki błędów w kodzie, który sam oddałeś.
• Co nie wchodzi: nowe funkcje, migracja majora frameworka i zmiana środowiska uruchomieniowego, zmiany wymuszone przez zewnętrznego dostawcę (bramka płatności, API kuriera), odzyskiwanie po włamaniu.
• Bank godzin: ile godzin drobnych zmian wchodzi w stawkę, czy przechodzą na kolejny miesiąc i po ilu miesiącach wygasają. Bez terminu wygaśnięcia dostajesz w grudniu żądanie odpracowania całego roku.
• Czas reakcji osobno od czasu naprawy. Reakcję kontrolujesz, naprawę nie, jeśli zależy od hostingu klienta albo dostawcy zewnętrznego.
• Dostępy: kto trzyma domenę, rejestratora i konto hostingowe oraz co się dzieje, gdy ktoś poza umową wgra wtyczkę. Bez tego zapisu płacisz za skutki cudzych zmian.
• Co się dzieje po wypowiedzeniu: że z końcem abonamentu kończy się obowiązek aktualizacji, i że klient ma to na piśmie, zanim strona zostanie bez łatek.

Przestawienie modelu rozliczeń z projektów na stałe abonamenty to zmiana w ofercie, a nie dopisek do niej: inny rytm sprzedaży, inne prognozowanie przychodu i inna rozmowa z klientem, który dotąd płacił za wdrożenia. Praktyczny opis tego przejścia dla wykonawców jest w materiale o budowaniu usługi abonamentowej zamiast kolejnych zleceń projektowych.

Jaką stawkę wpisać i kiedy jej nie wpisywać

Rachunek domyka się czterema składnikami, w tej kolejności:

• liczba zdarzeń miesięcznie z pierwszego polecenia razy zmierzony czas jednostkowy po klasach,
• jedna dwunasta rocznego budżetu na migracje z kalendarza EOL,
• rezerwa na zdarzenie klasy czwartej, liczona jako prawdopodobny czas razy częstość z własnej historii,
• całość razy stawka godzinowa, którą stosujesz w projektach, bez rabatu za „to tylko utrzymanie”.

Pamiętaj, że te godziny nie są dodatkowe — konkurują o tę samą przepustowość, z której sprzedajesz projekty, i jeśli utrzymanie wchodzi bez wyceny, to ogranicza zdolność całej firmy, co dobrze pokazuje rachunek wąskiego gardła w firmie usługowej.

Dla projektu z dwudziestoma zdarzeniami miesięcznie, w większości patchami, z jednym majorem na kwartał i dwiema migracjami środowiska w ciągu dwóch lat, wychodzi zwykle kilka godzin miesięcznie. Policz to na swoich danych i porównaj z kwotą, którą miałeś zamiar wpisać. Jeśli wychodzi istotnie więcej, masz dwa wyjścia i oba są uczciwe: podnieść stawkę do wyniku rachunku albo wyłączyć aktualizacje z abonamentu i sprzedawać je jako osobne, planowane prace z datami z kalendarza EOL. Czego nie da się zrobić, to zostawić niskiej stawki i zakresu „utrzymanie strony” — wtedy pierwszy major frameworka zapłaci z Twojej marży, a drugi z relacji z klientem.