Historia, która brzmi znajomo
Marta, founderka SaaS w fazie pre-seed, dostała zielone światło od inwestora. Warunek: ma zamknąć development pierwszej wersji produktu za maksymalnie 120 tysięcy złotych. Zanim jeszcze porozmawiała z jakimkolwiek developerem, budżet był już przypięty do ściany.
Zaczęła zbierać oferty. Jeden software house powiedział 100 tys., drugi 150 tys., trzeci 200 tys. Ten za 100 tys. dostał projekt — bo „mieścił się w budżecie“. Po trzech miesiącach okazało się, że za 100 tys. dostała połowę funkcji, kod bez testów i architekturę, którą trzeba było przepisać po kolejnych dwóch miesiącach.
Budżet, który miał być jej zabezpieczeniem, okazał się pułapką.
Dlaczego „Ile to kosztuje?“ to najgorsze pytanie, jakie możesz zadać
Z pozoru brzmi niewinnie. Ale to pytanie zakłada, że koszt jest cechą inherentną produktu — taką jak kolor czy waga. W IT jest dokładnie odwrotnie.
Koszt jest wypadkową trzech zmiennych:
- Zakresu — co dokładnie ma powstać
- Jakości — jak solidnie ma być zrobione
- Ryzyka — czego jeszcze nie wiemy
Jeśli pytasz „ile to kosztuje“ bez zdefiniowania tych trzech rzeczy, każda liczba, którą usłyszysz, będzie kłamstwem. Albo zaniżonym, żeby wygrać przetarg. Albo zawyżonym, żeby przykryć niewiadome.
Prawidłowa kolejność jest odwrotna: najpierw zakres, potem estymacja, na końcu budżet.
Konsekwencje ustalania budżetu po omacku
Niski budżet = negatywna selekcja wykonawców
Jeśli powiesz software house’owi: „mam 80 tysięcy“, dzieją się dwie rzeczy. Dobry wykonawca, który realnie wycenia projekt na 150 tysięcy, po prostu odmówi. Wie, że nie wyrobi się w tym budżecie bez rżnięcia jakości. Zostają ci, którzy są zdesperowani lub niekompetentni — tacy, którzy powiedzą „tak“ na wszystko, byle podpisać umowę.
To zjawisko nazywa się selekcją negatywną. Im niższy budżet, tym gorszy średni poziom wykonawców, którzy są gotowi go przyjąć. Oszczędność na wejściu zamienia się w dług techniczny, opóźnienia i przepalony budżet na poprawki.
Wysoki budżet = przepłacanie
Z drugiej strony, jeśli masz budżet 300 tysięcy, a realny koszt to 150 tysięcy, to przy braku transparentnej wyceny zapłacisz 300. Software house nie ma powodu zejść z ceny, skoro sam podałeś kwotę.
Brak benchmarku = chaos
Najgorszy scenariusz: nie masz żadnego budżetu, ale też nie masz scope’u. Wtedy każda oferta jest porównywana z inną ofertą, a nie z realiami projektu. Wygrywa ten, kto ładniej opowie historię, a nie ten, kto rzetelniej oszacował pracę.
Prawidłowy proces: od scopu do budżetu
Oto jak powinien wyglądać proces, który chroni zarówno klienta, jak i dostawcę:
Krok 1: Zdefiniuj zakres, nawet pobieżnie
Nie potrzebujesz dokumentacji wymagań na 50 stron. Potrzebujesz listy: co system ma robić, jakie integracje są kluczowe, kim są użytkownicy. Nawet punktory w Google Docs są lepsze niż „zróbcie mi apkę“.
Krok 2: Przeprowadź discovery (lub poproś o nie)
Jeśli zakres jest niejasny, zleć osobny etap discovery. To kosztuje 5–15 tysięcy, ale zwraca się wielokrotnie. Discovery zamienia „zróbcie mi apkę“ w konkretny backlog z oszacowanymi user story.
Krok 3: Poproś o estymację z założeniami
Dobra estymacja to nie jedna liczba. To:
- Zakres prac z podziałem na fazy
- Założenia, które muszą być spełnione
- Lista ryzyk i obszarów niepewności
- Warianty: MVP, wersja rozszerzona, wersja pełna
Krok 4: Zdecyduj o budżecie
Dopiero teraz masz dane, żeby podjąć decyzję. Wiesz, że MVP kosztuje 100 tysięcy, wersja pełna 180 tysięcy, a ryzyko integracji z systemem księgowym może dodać 20 tysięcy. Możesz wybrać wariant albo negocjować zakres.
Jak czytać ofertę software house’u — czerwone flagi
Uczciwa oferta wygląda tak:
- Jest podział na fazy — discovery, design, development, QA, wdrożenie
- Są założenia — co musi dostarczyć klient, co jest po stronie dostawcy
- Są bufory ryzyka — wprost napisane, że dany obszar jest niepewny i może wpłynąć na koszt
- Jest opis zakresu — co dokładnie powstanie, a co jest poza zakresem
Czerwone flagi:
- Jedna zbiorcza kwota bez rozbicia
- Brak założeń i warunków brzegowych
- „Gwarantowana cena“ bez opisu zakresu
- Brak informacji o standardach jakości, testach, dokumentacji
- Presja czasowa („promocja ważna do piątku“)
Jeśli oferta nie mówi, co dokładnie dostajesz za podaną kwotę, to nie jest oferta — to zgadywanka.
Rola transparentnej wyceny w budowaniu zaufania
Tu pojawia się kluczowa kwestia: wycena to nie tylko liczba, to narzędzie komunikacji.
Kiedy software house przedstawia ofertę z rozbiciem na fazy, założeniami i buforami ryzyka, robi coś ważniejszego niż podanie ceny — pokazuje, że rozumie Twój projekt i myśli o nim w kategoriach realnych, a nie życzeniowych.
Z drugiej strony, jako klient masz prawo oczekiwać, że wycena będzie czytelna. Że zobaczysz nie tylko „200 godzin“, ale też: co dokładnie powstanie w tych godzinach, jakie są założenia, jakie ryzyka zostały skalkulowane w cenie.
Transparentna oferta pozwala Ci podjąć świadomą decyzję. Nie musisz być CTO, żeby zrozumieć, za co płacisz. Wystarczy, że oferta jest napisana ludzkim językiem, a nie technicznym żargonem.
Checklista: jak przygotować się do rozmowy z software housem
Zanim wyślesz zapytanie ofertowe, przejdź przez tę listę:
- Mam spisany zakres — nawet w punktach. Wiem, co system ma robić.
- Mam priorytety — wiem, co jest must-have, a co nice-to-have.
- Mam przykłady — screeny, opisy, konkurencja, którą znam. To pomaga developerowi zrozumieć kontekst.
- Mam świadomość ryzyk — wiem, które integracje są skomplikowane, które dane są nieczyste.
- Nie podałem budżetu — mówię o zakresie, a nie o kwocie. Budżet ustalam po estymacji, nie przed.
- Planuję discovery — jeśli zakres jest niejasny, mam w budżecie osobną fazę analizy.
- Sprawdzam referencje — nie tylko portfolio, ale opinie innych klientów o współpracy.
Podsumowanie
Budżet projektu IT nie powinien być punktem wyjścia do estymacji — powinien być jej wynikiem. Ustalanie ceny przed poznaniem zakresu to gwarancja złej decyzji. Albo przepłacisz, albo dostaniesz byle co, albo wybierzesz złego wykonawcę.
Zanim podasz swój budżet software house’owi, najpierw poznaj zakres. Wtedy koszt będzie wynikiem analizy, a nie zgadywanką. A jeśli software house nie potrafi przedstawić transparentnej wyceny z podziałem na fazy i ryzyka — potraktuj to jako czerwoną flagę.