Mój pierwszy duży projekt wyceniłem na 18 tysięcy złotych. Skończył się na 47 tysiącach (mojej pracy) i 18 tysiącach (zapłacone). Strata 29 tysięcy plus 4 miesiące życia. Powód? Nie wiedziałem nic o wycenie projektów IT.

Dziś wiem. I wycena, którą robię w 30 minut, jest dokładniejsza niż wtedy w 3 dni. Ten post to wszystko, co bym powiedział sobie 8 lat temu. Plus to, czego nauczyłem się prowadząc dziesiątki projektów w agencji.

Trzy modele rozliczeń

Każda wycena zaczyna się od decyzji: jak rozliczamy projekt.

Time and materials (T&M). Klient płaci za przepracowane godziny. Najprostszy, najmniej ryzykowny dla wykonawcy, ale klient ma niepewność kosztu końcowego. Mój standard dla 70% projektów.

Fixed price. Klient płaci ustaloną kwotę za ustalony zakres. Mniej elastyczne, większe ryzyko dla wykonawcy, ale klient ma pewność budżetu. Stosuję dla 20% projektów, gdzie zakres jest naprawdę dobrze zdefiniowany.

Retainer (subskrypcja). Klient płaci stałą kwotę miesięcznie, dostaje określoną liczbę godzin lub support. Najlepsze dla długoterminowych klientów, którzy potrzebują ciągłego wsparcia. 10% moich kontraktów.

Większość początkujących wybiera fixed price, bo “tak chciał klient”. To zwykle błąd.

Dlaczego fixed price jest pułapką

Klient pyta: “Ile będzie kosztował projekt?”. Programista, chcąc się popisać precyzją, daje konkretną liczbę. Ten moment psuje cały dalszy projekt.

Bo:

  • Nie znasz wszystkich wymagań. Klient sam ich nie zna. Wyjdą w trakcie.
  • Nie znasz technicznego długu. Refaktor, migracja, integracja z legacy = niespodzianki.
  • Nie znasz prawdziwego scope creepu. Klient powie “to tylko mała zmiana” 50 razy.
  • Nie znasz produktywności. Twoja własna w nieznanej dziedzinie może być 30% normalnej.

Fixed price działa tylko, gdy:

  1. Robisz coś, co już robiłeś (np. dziesiąty sklep WooCommerce)
  2. Wymagania są spisane w dokumencie, do którego się odwołujesz
  3. Masz bufor 50%+ na niespodzianki
  4. Klient akceptuje, że “extra scope” idzie poza umowę

Jeśli któryś z tych warunków nie jest spełniony, idziesz w T&M.

Jak liczyć T&M (czyli stawkę godzinową)

Krótko, bo o tym pisałem szerzej w ile zarabia programista.

Formuła rozsądnej stawki:

(pożądana pensja roczna / 11 miesięcy / 120 godzin pracy zarabialnej miesięcznie)
+ podatki (12-19%)
+ ZUS (1400-3000 zł miesięcznie / 120h)
+ koszty firmowe (200-500 zł / 120h)
+ bufor wakacyjny (10%)

Programista średni: chce 15k netto miesięcznie = stawka 200-250 zł/h.
Programista senior: chce 25k netto = stawka 350-450 zł/h.
Programista expert / niszowy: 500-800 zł/h.

Im wyższa stawka, tym mniej godzin musisz wystawić, żeby dożyć do końca miesiąca. To kluczowe, bo nigdy nie pracujesz pełnych 160h/miesiąc na klienta. 120h to realistyczny benchmark.

Jak wyceniać fixed price, jeśli musisz

Jeśli klient absolutnie wymaga fixed price (np. budżet publiczny, sztywna procedura zakupowa):

Krok 1: rozbij projekt na małe taski. 1-8h każdy. Nie 40h. Nie 80h. Małe taski = większa dokładność.

Krok 2: estymuj każdy task w 3 wariantach.

  • Optymistyczny (jak wszystko pójdzie dobrze): O
  • Realistyczny (typowo): R
  • Pesymistyczny (jak coś się posypie): P

Wzór PERT: estymata = (O + 4R + P) / 6. Daje rozsądne wyważenie.

Krok 3: zsumuj wszystkie taski. Dostajesz sumę godzin S.

Krok 4: dodaj bufor. Standard:

  • 20% dla projektów w dziedzinie, którą znasz dobrze
  • 30% dla projektów standardowych
  • 50% dla projektów z nieznanymi elementami
  • 100% dla projektów R&D

Krok 5: pomnóż przez stawkę. Cena = (S + bufor) × stawka godzinowa.

Krok 6: dodaj 10-15% na “communication overhead”. Spotkania, emails, screen-sharing, dokumentacja.

Po tym dostajesz cenę, którą podajesz klientowi. Nie pokazujesz mu breakdown’u na taski. Pokazujesz total.

Czego nie liczyć w estymacji (a wszyscy liczą)

“Mam już komponent X”. Liczysz, że zaoszczędzisz 8 godzin. Realnie i tak musisz go adaptować, debugować w nowym kontekście, integrować. Zaoszczędzisz 2 godziny. Nie wliczaj.

“AI mi to napisze”. Cursor i Claude Code dają 30-40% boost (pisałem w osobnym poście). Ale tylko w fazie kodowania. Architektura, testy, debug, komunikacja to nadal 100% Twojego czasu.

“Ten klient jest mały, szybko zrobię”. Wielkość klienta nie ma związku ze złożonością projektu. Czasem startupy są trudniejsze niż korpo.

“Klient powiedział, że ma już design”. Sprawdź, zanim wycenisz. “Mam design” zwykle znaczy “mam schemat na kartce” albo “mam mockup, który nie pasuje do realnych danych”.

Co liczyć, o czym wszyscy zapominają

Onboarding do projektu. Czytanie istniejącego kodu, rozumienie biznesu klienta, dostępy, środowiska. Pierwsze 2 tygodnie to często 50% produktywności.

Komunikacja. Daily standupy, weekly reviews, status updates, ad-hoc calle. W projekcie 200-godzinnym to spokojnie 30 godzin samej komunikacji.

Code review. Twojego kodu (od klienta lub innych programistów), kolegów (jeśli klient ma zespół). 10-15% projektowych godzin.

Testy. Pisanie, uruchamianie, naprawianie. Łatwo +30% do estymacji feature’u.

Deployment i monitoring. Konfiguracja CI/CD, monitoring, alerting. Zwykle 10-20 godzin na projekt.

Bugfix po wdrożeniu. Pierwsze 2-4 tygodnie produkcji to chaos. Wlicz w wycenę 20-40h post-launch supportu.

Dokumentacja. README, ADRs, runbooks. Tak, klient za to płaci. Tak, mu się przyda.

Jak rozmawiać z klientem o wycenie

Najgorsza odpowiedź: “Dużo, około 50 tysięcy”. Nie wiesz, dlaczego, klient nie wie, dlaczego. Pole do negocjacji jest puste.

Lepsza odpowiedź: “Projekt rozbiłem na 23 epiki. Z mojego doświadczenia podobne projekty zajmują 280-340 godzin. Przy stawce 350/h cena to 98-119 tysięcy. Mogę wysłać Ci breakdown w PDF do akceptacji”.

Klient widzi, że myślałeś. Widzi, że masz proces. Widzi widełki, nie sztywną liczbę. Negocjacja staje się merytoryczna, nie emocjonalna.

Klauzula “scope creep” w umowie

Klient zawsze chce więcej. To nie złośliwość, to natura projektów. Zabezpieczenie:

W umowie wpisz:

“Zmiany w zakresie projektu wymagające ponad X godzin dodatkowej pracy są rozliczane oddzielnie po stawce Y zł/h, po pisemnej akceptacji przez obie strony.”

Threshold X to zwykle 4-8h. Czyli “drobiazgi do 4h dorzucam za darmo, większe rzeczy wyceniamy”.

Ta klauzula nie sprawi, że klient przestanie chcieć więcej. Sprawi, że będzie świadomy kosztów. To znaczna różnica.

Negocjacja: kiedy spuścić, kiedy nie

Klient mówi: “Twoja wycena jest 30% droższa niż konkurencja”. Możliwe scenariusze:

Spuść cenę, jeśli:

  • Konkurencja faktycznie jest tańsza (sprawdź)
  • Klient strategiczny (referencje, dalsze projekty)
  • Projekt da Ci wejście do nowej branży / technologii
  • Możesz znaleźć cięcia w scope, które uzasadniają niższą cenę

Nie spuszczaj ceny, jeśli:

  • Klient po prostu próbuje
  • Konkurencja oferuje gorszy product
  • Spadek ceny wymaga skrócenia czasu (jakość ucierpi)
  • Po wymuszeniu zniżki klient i tak będzie wymagał pełnego scope’u

Mój standard: maksymalnie 10% zniżki. Powyżej zaczynam ciąć scope, nie cenę.

Co robić, jeśli się pomyliłeś w wycenie

Zdarza się. Ważne, co robisz potem.

Mała pomyłka (do 20%): weź na klatę. Naucz się na przyszłość. Klient się nie dowie.

Średnia pomyłka (20-40%): zgłoś klientowi szczerze. “Projekt okazał się trudniejszy w obszarze X. Mogę dokończyć w obecnej cenie, albo zwiększyć budżet o Y i dostać dodatkową funkcjonalność Z. Twoja decyzja”.

Duża pomyłka (40%+): stop, negocjacje, możliwy reset. Nie kontynuuj projektu, który Cię zabija finansowo. Lepiej stracić tego klienta niż zbankrutować, próbując mu dogodzić.

Pisałem o tym, jak negocjować umowy w poście o umowach B2B. Te umiejętności są blisko spokrewnione.

Co czytać dalej

  • “Pricing Creativity” Blair Enns. Mocna teoria value-based pricingu (cena oparta na wartości dla klienta, nie na godzinach).
  • “Million Dollar Consulting” Alan Weiss. Klasyk konsultingowy, dobrze tłumaczy psychologię klienta przy wycenie.
  • Blog Jonathan Stark. Jonathan jest amerykańskim freelancerem, który napisał setki postów o ditching hourly billing. Część jego rad nie pasuje do polskiego rynku, ale fundamenty są uniwersalne.

Od czego zacząć

Jeśli właśnie wyceniasz pierwszy projekt:

  1. Wybierz T&M, nie fixed price (chyba że klient absolutnie wymaga).
  2. Policz swoją realną stawkę godzinową (formuła wyżej).
  3. Rozbij projekt na taski maksymalnie 8h każdy.
  4. Estymuj PERT-em (optymistyczny, realistyczny, pesymistyczny).
  5. Dodaj 30% bufora minimum.
  6. Wpisz w umowę klauzulę scope creep.

Twoja pierwsza wycena będzie zła. To OK. Druga będzie lepsza. Po dziesiątej masz intuicję, która prawie zawsze trafia. Klucz to mierzyć (faktyczne godziny vs estymata) i uczyć się z każdego projektu.

Nie ma magii w wycenie projektów IT. Jest tylko proces. Im więcej projektów, tym dokładniejszy proces. Pierwsze 5 projektów wycenisz z 50% błędem. Po 20 projektach błąd spadnie do 15%. Tyle wystarczy, żeby agencja generowała marżę.