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.

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

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, backup, 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 backupu. Mimo to dobrze pokazują, że odtworzenie jest częścią podstawowej higieny, a nie dodatkiem po awarii.

Dotyczy to również designu. SEI opisuje design system jako wielokrotnego użytku źródło prawdy z komponentami i wzorcami. Z tego wynika praktyczna korzyść: style guide 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ć.