Ile godzin developera miesięcznie potrzebuje aplikacja?

Co realnie daje pakiet 10–20 godzin miesięcznie?

Mały pakiet dobrze pasuje do zadań, które wracają, ale nie wymagają pełnego etatu: aktualizacji, przeglądu błędów, małych integracji, konsultacji, code review, porządkowania backlogu i kilku godzin rozwoju. Przedział 10–20 godzin nie jest rynkowym standardem ani wynikiem badania — to praktyczny model do sprawdzenia na konkretnym backlogu. W TreeTank rezerwacja dostępności zaczyna się od 20 godzin miesięcznie, a mniejsze potrzeby można rozliczać doraźnie.

Największą wartością może nie być sama liczba napisanych linijek. Developer zachowuje kontekst aplikacji, pamięta wcześniejsze decyzje, może wcześniej zauważyć ryzyko i nie musi za każdym razem poznawać systemu od zera. To obserwacja z modelu współpracy, nie obietnica, że każda godzina pakietu automatycznie oszczędza określoną liczbę godzin właściciela produktu.

• dobry zakres: powtarzalny backlog, aktualizacje, małe poprawki, konsultacje i review;
• gorszy zakres: kilka dużych funkcji prowadzonych równolegle bez priorytetu;
• inny produkt: dyżur, SLA i reakcja poza ustalonymi godzinami.

Pakiet nie zastępuje projektu ani dyżuru

Jeśli przez kilka miesięcy budujesz jedną dużą funkcję, nazwij ją projektem z zakresem, estymacją i limitem. Pakiet godzin sprawdza się przy małych zadaniach, ale może ukrywać większy projekt, gdy każda rozmowa zaczyna się od innego priorytetu i nie ma czasu na domknięcie.

Dyżur 24/7 wymaga określonych czasów reakcji, zastępstwa, monitoringu i procedury eskalacji. Kilkanaście godzin pracy miesięcznie może przygotować aplikację do spokojnego utrzymania, ale nie jest samo w sobie obietnicą, że ktoś będzie dostępny w każdej minucie awarii.

Praca przy Trans.info pokazała mi jeszcze jedną granicę, ale nie chcę opisywać jej wyłącznie jako rozsądnego priorytetyzowania utrzymania. Z perspektywy zarządzania był to mismanagement: przez kilka lat bieżące utrzymanie dominowało nad zaplanowaniem migracji, a etapowa ścieżka nie została wcześniej potraktowana jako realna opcja. Developer powinien mieć przestrzeń, żeby proaktywnie powiedzieć, że można migrować po kawałku; jeśli takiej przestrzeni nie ma, pakiet godzin tylko utrwala bieżący stan. Gdy migracja jest potrzebna, trzeba przydzielić jej osobny zakres i rozważyć mniejsze, odwracalne kroki, a nie liczyć na resztki pakietu godzin.

AI przyspiesza pracę, ale nie usuwa utrzymania

AI może przyspieszyć analizę logów, wyszukiwanie miejsc do zmiany, pisanie testów, dokumentowanie i przygotowanie małych poprawek. Nie usuwa jednak potrzeby sprawdzenia wyniku, aktualizacji zależności, obserwowania produkcji, backupu i decyzji, czy dana zmiana rzeczywiście odpowiada procesowi firmy.

DORA 2025, oparty na odpowiedziach prawie 5 tysięcy profesjonalistów, odnotował dodatni związek adopcji AI z przepustowością dostarczania i wydajnością produktu oraz ujemny związek ze stabilnością dostarczania. To związek statystyczny, nie dowód, że samo AI powoduje niestabilność. W eksperymencie METR z początku 2025 roku 16 doświadczonych developerów wykonało 246 zadań; przy dozwolonym użyciu AI trwały one średnio o 19% dłużej, z przedziałem niepewności od 2% do 39%. Wynik dotyczył dużych repozytoriów open source i konkretnego zestawu narzędzi, więc nie jest uniwersalną oszczędnością ani cennikiem pracy. Uczciwe rozliczenie powinno obejmować potrzebną pracę i efekt, a nie fikcyjne ręczne czynności, których narzędzie nie musiało wykonywać.

Szybka aplikacja nie zawsze ma świeże dane

Po wdrożeniu pierwszych wersji Trans.info poprawiliśmy obsługę grafik i pamięć podręczną. Optymalizację grafik przenieśliśmy do WordPressa, a później poprawiliśmy także ich przekazywanie przez Next.js oraz przechowywanie treści w kilku warstwach: WordPressie, Elasticsearchu i Next.js. Większość pamięci podręcznej była oparta na plikach, ponieważ rozbudowa stosu technologicznego byłaby zbyt kosztowna i niedopuszczona w tym środowisku. Dzięki temu serwer obsługujący stronę działał bardzo szybko.

Problem ze statusami wpisów nie pojawił się od razu. Dopiero po około dwóch latach ujawniła się uboczna konsekwencja długiego przechowywania danych: niektóre zmiany statusów nie odświeżały się wystarczająco szybko. Dodaliśmy więc mechanizmy wymuszonego odświeżania konkretnych danych. Rzadko trzeba było ich używać, ale sama możliwość ręcznego odświeżenia okazała się ważna.

Ta historia nie oznacza, że pamięć podręczna była błędem. Pokazuje raczej, że wydajność i aktualność danych trzeba projektować razem. System może działać szybko przez lata, a później wymagać dodatkowej drogi odświeżenia, gdy zmieni się sposób pracy redakcji.

Własne narzędzie czy SaaS? Policz cały cykl życia

Własny system może być opłacalny, gdy obsługuje specyficzny i powtarzalny proces, którego gotowe narzędzia nie potrafią dobrze odwzorować. SaaS zwykle wygrywa przy standardowym problemie, szybkim starcie i potrzebie gotowych aktualizacji. Eurostat podaje, że w 2025 roku 52,7% badanych przedsiębiorstw w UE używało płatnych usług chmurowych; wśród firm korzystających z takiej chmury 26,1% używało platform do tworzenia, testowania lub wdrażania aplikacji. Drugiej liczby nie wolno czytać jako 26,1% wszystkich przedsiębiorstw.

Porównaj horyzont odpowiadający planowanemu życiu rozwiązania; robocze 24–36 miesięcy pomaga zobaczyć koszty, ale nie jest uniwersalnym progiem. Uwzględnij abonament, użytkowników, limity, eksport danych, integracje, szkolenie, ręczną pracę, aktualizacje, backup, monitoring, zmianę dostawcy i zastępstwo autora. Własne narzędzie ma sens, jeśli regularnie oszczędza czas, zmniejsza ryzyko albo daje kontrolę, której nie można kupić — nie tylko dlatego, że pierwszą wersję da się szybko wygenerować.

Utrzymanie zaczyna się jeszcze przed przekazaniem

Prototyp albo nowa aplikacja są łatwiejsze do utrzymania, gdy mają README, opis danych, przykładową konfigurację, listę zależności, sposób wdrożenia, kopię zapasową, logi i sekcję z ograniczeniami. W danych Eurostatu za 2024 rok 93% badanych przedsiębiorstw stosowało przynajmniej jeden środek bezpieczeństwa ICT, a 79% przechowywało kopię zapasową osobno; to deklaracje przedsiębiorstw objętych badaniem, nie audyt jakości kopii. Mimo to dobrze pokazują, że odtworzenie jest częścią podstawowej higieny, a nie dodatkiem po awarii.

Dotyczy to również projektu wizualnego. SEI opisuje system projektowy jako wielokrotnego użytku źródło prawdy z komponentami i wzorcami. Z tego wynika praktyczna korzyść: przewodnik stylu i wspólne komponenty ograniczają powtarzanie decyzji przy kolejnych stronach, choć nie ma podstaw, by obiecywać jeden uniwersalny procent oszczędności. Poproś inną osobę o czyste uruchomienie projektu. Jeśli potrzebuje autora przy każdym kroku, system nie jest jeszcze gotowy do spokojnej opieki.

Dobra dokumentacja nie ma udawać, że nie ma ryzyka — ma pokazać, gdzie ono jest i jak zareagować.