Fixed price czy godziny? Jak rozliczyć projekt IT bez niespodzianek

Zlecasz projekt software'owy i dostajesz dwie wyceny: jedna to konkretna kwota „za całość”, druga to stawka za godzinę plus szacowany czas. Która jest dla Ciebie lepsza? To nie jest pytanie o to, który model jest „uczciwszy” — oba bywają uczciwe i oba bywają pułapką. Pytanie brzmi: który pasuje do Twojego projektu, budżetu i tolerancji na ryzyko. Poniżej rozkładam fixed price i rozliczenie godzinowe (time & material) na czynniki pierwsze — z plusami i minusami obu, bez udawania, że istnieje jeden słuszny wybór.

Dwa modele w pigułce

Fixed price (stała cena) to umowa na z góry ustalony zakres za z góry ustaloną kwotę. Wykonawca bierze na siebie ryzyko, że robota zajmie więcej, niż zakładał.

Time & material (godziny) to rozliczenie za faktycznie przepracowany czas według stawki godzinowej lub dziennej. Ryzyko niedoszacowania leży po Twojej stronie — płacisz za tyle pracy, ile realnie wejdzie.

Cała reszta to warianty i hybrydy tych dwóch. Najkrótsze porównanie wygląda tak:

Fixed price: plusy i minusy

Po stronie plusów:

• Przewidywalność budżetu. Znasz końcową kwotę przed startem. Łatwo zaplanować cash flow i przypisać konkretne złotówki do konkretnej pozycji.
• Ryzyko po stronie wykonawcy. Jeśli zadanie zajmie dwa razy dłużej, to jego problem, nie Twój — o ile zakres się nie zmienił.
• Prostsze rozliczenie. Jedna kwota, jasne kamienie milowe, brak comiesięcznego liczenia godzin i tłumaczenia się z każdej pozycji.

Po stronie minusów — i to trzeba powiedzieć wprost:

• Ryzyko niedoszacowania = bufor w cenie. Wykonawca, który bierze ryzyko na siebie, wlicza je w wycenę. Za przewidywalność płacisz narzutem, nawet jeśli projekt pójdzie gładko.
• Sztywność. Każda zmiana zakresu to renegocjacja. Model premiuje trzymanie się ustaleń, nie reagowanie na nowe pomysły z rynku.
• Pokusa cięcia jakości. Jeśli wykonawca źle wycenił, presja na „domknięcie” potrafi zejść na testy, edge case'y albo dokumentację. Dobra umowa i jasne kryteria odbioru to ograniczają, ale ryzyko istnieje.

Time & material: plusy i minusy

Plusy:

• Elastyczność. Zmieniasz priorytety w trakcie, dokładasz pomysł z researchu użytkowników, rezygnujesz z funkcji — bez aneksów do umowy za każdym razem.
• Płacisz za realną pracę. Brak bufora „na wszelki wypadek”. Jeśli projekt pójdzie sprawnie, zapłacisz mniej, niż wyniosłaby stała cena.
• Transparentność. Widzisz, na co schodzi czas. Przy uczciwym raportowaniu to świetne narzędzie do zarządzania, a nie tylko faktura.

Minusy — równie szczere:

• Ryzyko budżetowe po Twojej stronie. Niedoszacowanie to Twój problem. Faktura potrafi rosnąć szybciej niż sam produkt.
• Wymaga Twojego zaangażowania. Bez właściciela produktu, który pilnuje priorytetów, godziny rozpływają się w „drobnych poprawkach”.
• Trudniej porównać oferty. Niższa stawka godzinowa nie znaczy taniej — wolniejszy zespół po niższej stawce wyjdzie drożej. Stawka bez estymacji to połowa informacji.

Kiedy fixed price wygrywa

Stała cena ma sens, gdy:

• Zakres jest znany i stabilny. Wiesz, co budujesz — masz makiety, user stories, jasną definicję „gotowe”. Im lepiej opisany zakres, tym mniejszy bufor ryzyka w cenie.
• Budżet jest ograniczony i sztywny. Masz do wydania konkretną kwotę i nie możesz pozwolić sobie na niespodziankę na fakturze.
• Chcesz przewidywalności. Raportujesz do zarządu, inwestora albo wspólnika i potrzebujesz jednej liczby, a nie widełek „mniej więcej”.
• Projekt jest zamknięty. Wdrożenie, migracja, MVP z jasną listą funkcji — coś, co ma początek i koniec.

Kiedy godziny mają sens

Rozliczenie godzinowe wygrywa, gdy:

• Zakres jest zmienny z natury. Research, eksperymenty, produkt, który dopiero szuka product-market fit. Nie da się rzetelnie wycenić czegoś, czego kształt jeszcze nie istnieje.
• To długi, ciągły rozwój. Produkt rozwijany latami, z roadmapą, która żyje. Wymuszanie fixed price na każdym sprincie to więcej narzutu niż wartości.
• Priorytety zmieniają się szybko. Startup po launchu, w którym dane z rynku co tydzień przestawiają plany.
• Masz zespół i własność produktu. Potrafisz zarządzać backlogiem i realnie pilnować, na co schodzi czas.

Jak rozliczamy projekty w SEVENEDGE

Najczęstszy ból, jaki słyszymy od founderów, to nie „model X jest zły”, tylko „dostałem fakturę większą, niż się umawialiśmy”. Dlatego ułożyliśmy to tak, żeby tej sytuacji po prostu nie było:

• Transparentne widełki przed scoping callem. Zanim cokolwiek ustalimy, znasz rząd wielkości. Żadnego „to zależy” w nieskończoność — orientacyjny przedział dostajesz od razu, żeby było jasne, czy w ogóle gramy w tej samej lidze budżetowej. Aktualne widełki trzymamy na stronie cennik.
• Fixed price po ustaleniu zakresu. Na scoping callu domykamy, co dokładnie powstaje. Wychodzisz z niego ze stałą ceną i terminem — nie z włączonym licznikiem godzin.
• Nowy zakres = nowa propozycja, nie pęczniejąca faktura. Jeśli w trakcie pojawi się pomysł spoza ustaleń, dostajesz osobną, jasną wycenę tej zmiany. Decydujesz, czy wchodzisz. Faktura za pierwotny zakres się nie rusza.

To nie jest magiczny trzeci model — to fixed price poprzedzony uczciwym scopingiem, poukładany tak, żeby nie było niespodzianek. Dla projektów badawczych albo długiego rozwoju proponujemy rozliczenie godzinowe, ale mówimy o tym wprost, zamiast udawać, że wszystko da się zamknąć w jednej kwocie. Jak wygląda droga od zapytania do wdrożenia, rozpisaliśmy krok po kroku w naszym procesie.

Czego pilnować w umowie — niezależnie od modelu

Model rozliczeń to jedno. Umowa to drugie — i tu founderzy najczęściej się przejeżdżają. Niezależnie od tego, czy płacisz fixed, czy za godziny, sprawdź trzy rzeczy:

• Definicja zakresu. Co dokładnie wchodzi, a co nie. W fixed price to fundament ceny; w godzinach — punkt odniesienia, od którego liczysz odchylenia. „Zrobimy aplikację” to nie zakres. „Logowanie, panel z trzema rolami, integracja z systemem płatności” — to zakres.
• Kamienie milowe i kryteria odbioru. Kiedy płacisz, za co i jak poznajesz, że etap jest „gotowy”. Płatności powiązane z odbiorem działającego fragmentu chronią obie strony przed sporem o to, czy coś jest skończone.
• Własność kodu. Upewnij się, że kod i prawa autorskie przechodzą na Ciebie — najlepiej od pierwszego dnia, w Twoim repozytorium. Bez tego płacisz za coś, czego formalnie nie posiadasz, i ryzykujesz vendor lock-in.

Który model wybrać?

Skrót decyzji: znany zakres i sztywny budżet → fixed price. Zmienny zakres i długi rozwój → godziny. A jeśli nie jesteś pewien, po której jesteś stronie, to sam ten brak pewności jest sygnałem — warto najpierw usiąść do scopingu i zamienić mgłę w konkretną listę, zanim zdecydujesz o modelu.

Najgorszy wybór to model dopasowany do wygody wykonawcy, a nie do Twojego projektu. Drugi najgorszy to brak umowy, która jasno opisuje zakres, kamienie milowe i własność kodu — bo wtedy nawet najlepszy model rozliczenia Cię nie ochroni.

Jeśli chcesz zobaczyć konkretne widełki, zajrzyj na cennik. A jeśli wolisz najpierw zrozumieć, jak prowadzimy projekt od pomysłu do wdrożenia, opisaliśmy to w procesie współpracy. Wyceny nie zrobi się w próżni, ale dobry scoping zwykle szybko pokazuje, który model naprawdę gra na Twoją korzyść.