Dlaczego najtańsza oferta software house'u może kosztować Cię najwięcej

Wstęp

Kilka tygodni temu na Reddicie pojawiła się historia non-technical fundera, która idealnie ilustruje najdroższy błąd w outsourcingu IT. Facet potrzebował zbudować MVP swojego SaaS-a. Porównał oferty. Amerykańskie agencje chciały $100–150/h. Znalazł agencję offshore z Polski po $35/h. „Okazja“ — pomyślał. Zainwestował $17.500 za około 500h pracy.

Dostał działający produkt. Mógł go uruchomić, pokazać klientom, zbierać feedback. Sukces? Nie do końca.

Gdy po kilku miesiącach chciał dodać kolejną funkcję, okazało się, że kod pod maską to techniczny koszmar. Zero dokumentacji. Żadnych testów. Funkcje po 400 linii w jednym pliku. Trzy frameworki wymieszane bez sensu. W czystym, dobrze napisanym kodzie nowa funkcja zajęłaby 3 dni. W tym kodzie — 3 tygodnie. Rebuild od zera: $40.000.

Zamiast oszczędności, przepłacił dwukrotnie.

Dlaczego niska stawka godzinowa nie oznacza niskiego kosztu całkowitego

Oto sedno problemu: cena za godzinę to nie to samo co koszt całkowity. W inżynierii oprogramowania obowiązuje koncepcja TCO — Total Cost of Ownership. To, co zapłacisz za zbudowanie systemu, to tylko część rachunku. Reszta to koszty utrzymania, rozwijania i usuwania długu technicznego. A te potrafią być wielokrotnie wyższe niż sam build.

Kompetentny programista napisze funkcję w 100 linii, która jest czytelna, testowalna i udokumentowana. Niestandardowy wykonawca napisze tę samą funkcję w 400 liniach — działających, ale niemożliwych do utrzymania bez ryzyka. Obaj spędzą przy tym podobną liczbę godzin. Różnica ujawni się dopiero przy kolejnej zmianie.

Dla klienta końcowego różnica między „dobrym kodem” a „działającym kodem” jest niewidoczna przez pierwsze tygodnie czy miesiące. Widać ją dopiero wtedy, zmiana małej rzeczy kosztuje tyle, co napisanie systemu od nowa.

Tu leży kluczowa pułapka: niska stawka godzinowa często koreluje z niskimi standardami jakości. To nie jest złośliwość — ktoś, kto sprzedaje czas tanio, musi ciąć koszty. A pierwsze, co zwykle leci, to czas na testy, dokumentację, code review i refactoring. Efekt? Kod, który działa, ale którego nikt nie chce tknąć.

Czego nie pokazuje typowa oferta

Większość ofert software house’ów wygląda tak samo: stawka, liczba godzin, podsumowanie. Zero informacji o tym, jak będzie powstawał kod.

Oto czego w ofercie nie zobaczysz, a powinieneś:

• Standardy kodowania — czy zespół ma zdefiniowane reguły (linting, formatowanie, architektura)? Kto je egzekwuje?
• Testy — czy w wycenę wliczone są testy jednostkowe, integracyjne, E2E? Jaki jest wymagany poziom pokrycia?
• Code review — każda zmiana przechodzi przez przynajmniej jedną parę oczu? Kto to robi?
• Dokumentacja — co dokładnie powstanie? Opis architektury? README? Dokumentacja API? Diagramy?
• CI/CD — jak wygląda pipeline wdrożeniowy? Automatyczne testy przed deployem?
• Refactoring — ile czasu jest zakładane na utrzymanie czystości kodu?

Jeśli oferta milczy na te tematy, to znaczy, że albo nie ma tych procesów, albo nie chce ich ujawnić. W obu przypadkach to czerwona flaga.

Jak ocenić jakość oferty, gdy nie jesteś techniczny

Nie musisz umieć programować, żeby zweryfikować jakość oferty. Potrzebujesz tylko kilku konkretnych pytań:

1. „Jaki jest wasz proces code review?“ — Jeśli odpowiedź brzmi „każdy kod sprawdza druga osoba”, to dobrze. Jeśli „mamy seniorów, którzy ogarniają“ albo „robimy to w razie potrzeby“, to źle.

2. „Czy w wycenę wliczone są testy? Jeśli tak, to jakie?“ — Dobra odpowiedź: „jednostkowe + integracyjne, minimum 70% pokrycia”. Zła: „testujemy ręcznie przed wdrożeniem“.

3. „Jak wygląda dokumentacja, którą dostanę?“ — Dobra odpowiedź wskazuje konkretne artefakty (diagram architektury, opis API, README). Zła: „dokumentujemy w Jira/Confluence” (czytaj: nie dokumentujemy nic).

4. „Jaka jest wasza polityka wobec długu technicznego?“ — To pytanie-zabójca. Jeśli nie wiedzą, o co pytasz, uciekaj.

5. „Możecie pokazać fragment kodu z poprzedniego projektu?“ — Nie musisz go rozumieć. Poproś swojego technicznego znajomego albo zewnętrznego audytora o rzut oka.

Czerwone flagi w ofercie

• Brak informacji o procesie wytwarzania — oferta zawiera tylko stawkę i zakres
• Brak gwarancji jakości — żadnych SLA, żadnych kryteriów akceptacji jakości kodu
• „Zrobimy to szybko i tanio“ — w IT te trzy słowa razem to zawsze kłamstwo
• Brak opisu zespołu — nie wiesz, kto będzie pracował nad twoim produktem
• „Wszystko w Fix Price“ przy nieprecyzyjnym scope — to oznacza, że albo zapłacisz za bufor ryzyka, albo dostaniesz minimum i resztę jako change requesty

Jak transparentna wycena chroni przed długiem technicznym

Tu wracamy do sedna: gdyby ten founder z Reddita dostał ofertę, która nie tylko mówiła „$35/h × 500h = $17.500“, ale zawierała:

• rozbicie na fazy: discovery, development, testy, dokumentacja, wdrożenie
• wskazanie standardów jakości i procesów
• bufory na refactoring i nieprzewidziane komplikacje
• jasny opis tego, co nie wchodzi w zakres (i ile kosztuje osobno)

…to mógłby świadomie porównać ofertę za $17.500 z ofertą za $35.000. I zobaczyć, że ta druga nie jest droższa — jest bardziej kompletna.

Transparentna wycena to nie tylko cena. To zestaw informacji, które pozwalają podjąć decyzję na podstawie faktów, a nie domysłów. Jeśli software house mówi: „testy to 20% budżetu, code review 10%, refactoring 10%“, to wiesz, że te rzeczy są realnie zaplanowane. Jeśli milczy, to znaczy, że prawdopodobnie ich nie ma.

W tym kontekście narzędzia, które wymuszają strukturalne podejście do wyceny — rozbicie na kategorie, bufory, założenia, ryzyka — nie są „biurokracją“. Sę ochroną przed sytuacją, w której $17.500 zamienia się w $57.500.

Checklista dla klienta: jak wybrać software house nie tylko po cenie

Zanim podpiszesz umowę, sprawdź:

Proces i standardy

• Zespół ma zdefiniowany proces code review
• Istnieją standardy kodowania (linting, architektura)
• Są wdrożone automatyczne testy (jednostkowe, integracyjne)
• Projekty mają dokumentację techniczną

Transparentność oferty

• Oferta zawiera rozbicie na fazy i kategorie prac
• Są jasno opisane założenia i warunki brzegowe
• Wskazano bufory na ryzyko i refactoring
• Określono, co nie wchodzi w zakres

Zespół

• Wiadomo, kto będzie pracował nad projektem
• Są znane kompetencje i doświadczenie zespołu
• Istnieje pojedynczy punkt kontaktowy (PM/TA)

Po dostarczeniu

• Kod jest przekazywany z dokumentacją
• Są testy, które można uruchomić
• Istnieje okres gwarancji na poprawki
• Wiesz, jakie są koszty utrzymania po wdrożeniu

Podsumowanie

Historia fundera, który zapłacił $17.500 za pozorną okazję, a potem $40.000 za naprawienie skutków, nie jest wyjątkiem. Powtarza się codziennie na całym świecie. Nie dlatego, że agencje offshore są złe — ale dlatego, że system wyceny nie wymusza transparentności.

Jako klient masz prawo wiedzieć, za co dokładnie płacisz. Nie tylko za godziny, ale za sposób, w jaki te godziny są wykorzystywane. Jakość ma koszt. Jeśli nie widzisz go w ofercie, zobaczysz go w utrzymaniu.

Zanim wybierzesz najtańszą ofertę, zapytaj: co dokładnie dostaję za tę cenę i ile będę musiał dopłacić za utrzymanie kodu w przyszłości?