Wycena oprogramowania w 2026 roku – jak ją prawidłowo przeanalizować i na jakie czerwone flagi zwrócić uwagę?

Wycena, którą właśnie dostałeś na maila, najprawdopodobniej jest nietrafiona.

Nie dlatego, że agencja, która ją przygotowała, próbuje Cię oszukać – po prostu szacowanie kosztów software'u z natury jest niedokładne. Po setkach wycenionych projektów doszedłem do wniosku, że celem nigdy nie była i nie powinna być bezbłędnie określona kwota. Chodzi o dobrze ułożony proces, który dąży do tego, by początkowe wyliczenia były jak najbardziej zbliżone do końcowych, ale też by odpowiednio wcześnie przewidywał momenty, kiedy projekt może zboczyć z wytyczonej ścieżki.

Flyvbjerg i Budzier, analizując 1471 projektów IT, naliczyli wśród nich średnio 27% przypadków przekroczenia budżetu, przy czym co szósty projekt przekraczał go mniej więcej o 200% (Flyvbjerg i Budzier, HBR 2011). Takie przekroczenie nie pojawia się znikąd w dniu odbioru projektu – ono jest ukryte w wycenie, którą właśnie otrzymałeś, tylko większość nie wie, gdzie go szukać. Częściowo ten brak precyzji jest po prostu wpisany w naturę branży i sam w sobie nie świadczy o niekompetencji dostawcy. Liczy się to, czy potrafi on tę niepewność co do ostatecznego kosztu pokazać i sensownie nią zarządzać. Głębszym przyczynom tego, dlaczego precyzyjne wycenienie software'u jest praktycznie niemożliwe, poświęciłem osobny tekst. Tutaj skupiam się na czymś innym – jak właściwie czytać wycenę, którą już masz przed sobą.

Zamiast więc powtarzać, że wyceny „powinny być dokładne" – co robi większość poradników – pokażę Ci konkretnie, jak odróżnić uczciwą wycenę od oferty sprzedażowej. Przejdziemy przez nasz 5-etapowy proces w TeaCode, sygnały ostrzegawcze, na które zwracam uwagę, gdy founderzy pokazują mi wyceny konkurencji oraz sposoby porównywania ofert, nawet jeśli każda z nich wygląda zupełnie inaczej.

Dlaczego żadna wycena projektu software'owego nigdy nie jest „dokładna" – i czemu to akurat jest ok

Jest jedno spojrzenie na ten problem, które zmieniło moje myślenie na temat ewaluacji wycen. Martin Fowler napisał w swoim eseju z 2003 roku, że zamiast mówić o projekcie jako opóźnionym czy przekraczającym budżet, warto powiedzieć, że to sama wycena zawiodła – „raport CHAOS nie dokumentuje porażek projektów software'owych, tylko porażki w ich szacowaniu" (Fowler, 2003).

To rozróżnienie jest ważne. Nie chodzi o to, czy wycena będzie dokładna co do grosza, tylko o to, czy jej metodologia jest na tyle uczciwa, żeby wszelkie odstępstwa od planu dało się kontrolować.

Wymagania projektowe są płynne. Użytkownicy dają feedback. Rynek się zmienia. Technologie ewoluują. Projekt, który nie reaguje na nowe informacje, to projekt, który dowozi zły produkt – mimo że jest dowieziony punktualnie i mieści się w budżecie. Powiedzmy, że ostateczny koszt projektu wycenionego na 80 tys. dolarów różni się od pierwotnej wyceny o 10–15% – to 8–12 tys. dolarów różnicy. Na pewno jest to odczuwalne i warte uwzględnienia, ale to jeszcze nie jest katastrofa budżetowa. Founderzy, którzy wpadają w panikę, to zwykle ci, których agencja nigdy nie uprzedziła, że taka zmiana w ostatecznej wycenie jest normalna.

Kiedyś branża posługiwała się koncepcją „stożka niepewności" – ilustracją tego, że na najwcześniejszym etapie wycena może się wahać od 0,25× do 4× ostatecznego kosztu. Ten stożek zwęża się dzięki konkretnym działaniom: prototypom, spike'om technicznym, dekompozycji zadań, opiniom od użytkowników. Obecnie w trakcie tworzenia produktów nie próbujemy na siłę ustalić idealnej wyceny na starcie, bo oprogramowanie to złożony system, w którym wymagania nieraz zmieniają się dopiero wtedy, gdy realni użytkownicy zaczną korzystać z produktu (choć nie dotyczy to każdego projektu – migracje, narzędzia wewnętrzne czy wdrożenia w branżach podlegających rygorystycznym regulacjom potrafią mieć znacznie stabilniejszy zakres cenowy). Zamiast tygodniami zgadywać ostateczny budżet, nowoczesne metodyki każą wycenić pierwszy, zwalidowany krok – czyli MVP – a resztę dostosowywać na bieżąco, na podstawie rzeczywistych danych i tempa pracy zespołu. To jest właśnie różnica między ślepym trzymaniem się specyfikacji a budowaniem tego, czego naprawdę potrzebuje rynek.

Prawdziwy problem leży w tym, jak agencje radzą sobie z niewiadomymi. Kontrakty typu firm-fixed-price przerzucają większość ryzyka związanego z nieprzewidzianymi kosztami na dostawcę, który – rzecz jasna – wlicza je w wycenę. Przy modelu Time & Materials płacisz za realnie przepracowane godziny, a wycena pełni raczej rolę punktu odniesienia niż sztywnego zobowiązania – choć umowa może zawierać limit budżetu albo próg wymagający Twojej zgody na przekroczenie. Obie strony mogą się wtedy elastycznie dostosowywać do warunków umowy w miarę rozwoju projektu. Problem w tym, że T&M przenosi na Ciebie większą część ryzyka związanego z kosztami, więc sprawdza się tylko wtedy, gdy aktywnie pilnujesz prac nad projektem, a przy tym też budżetu. Żaden z tych modeli nie jest z definicji korzystniejszy. O tym, jak utrzymać budżet w ryzach, kiedy rzeczywistość projektowa zaczyna odbiegać od planu, znajdziesz na naszej stronie dotyczącej tego, jak prowadzimy projekty w TeaCode.

Wiem, że to sporo do przetworzenia, a Ty pewnie chciałeś po prostu się dowiedzieć, ile rzeczywiście zapłacisz za swoją aplikację. Ale uczciwa odpowiedź brzmi: dobrze zaplanowana wstępna wycena da Ci sensowny przedział kosztowy dla Fazy 1 projektu, a wraz z postępem Discovery i samego developmentu, będzie się on zawężał. 

Ryzykom i kompromisom przy wyborze odpowiedniego modelu cenowego poświęciliśmy osobny, obszerny artykuł. Jeśli zastanawiasz się nad wyborem między fixed-price a T&M, sprawdź naszą analizę ryzyk związanych z kontraktami typu fixed-price. A jeśli wciąż się zastanawiasz, ile w ogóle powinien kosztować Twój projekt, zacznij od przewodnika po kosztach tworzenia oprogramowania w 2026 roku.

„Nie chodzi o to, czy wycena będzie dokładna co do grosza – tylko o to, czy jej metodologia jest na tyle uczciwa, żeby odstępstwa od planu dało się kontrolować."

Jakich metod szacowania kosztów używają firmy software'owe?

Firmy software'owe sięgają po kilka metod wyceny – warto znać cztery najpopularniejsze:: analogową, parametryczną, oddolną (bottom-up) i trzypunktową (PERT). Nie musisz być ekspertem od żadnej z nich, ale samo rozpoznanie, która stała za Twoją wyceną, powie Ci, na ile jest rzetelna. Większość agencji nie przedstawi Ci swojej metodologii, jeśli sam o nią nie zapytasz.

• Estymacja analogowa – polega na porównaniu Twojego projektu z podobnymi, wcześniej już zrealizowanymi. Jest szybka i wystarcza do wstępnej wyceny, ale jej wiarygodność zależy w dużej mierze od tego, jak trafnie dobrano projekt referencyjny i czy uwzględniono różnice między nim a Twoim.

• Estymacja parametryczna – opiera się na modelach matematycznych, takich jak COCOMO, które wyliczają koszt na podstawie zmiennych typu rozmiar czy złożoność projektu. Jest dość dokładna, ale wymaga solidnych danych, na których może się oprzeć.

• Estymacja oddolna (bottom-up) – rozbija każdą funkcję na pojedyncze zadania i sumuje potrzebne do ich wykonania godziny. To najbardziej szczegółowa i najłatwiejsza do zweryfikowania metoda, gdy zakres projektu jest już znany – choć jej trafność wciąż zależy od jakości dekompozycji, kalibracji na podstawie wcześniejszych projektów i tego, czy pominięte działania oraz powiązane z tym ryzyka faktycznie zostały uwzględnione w wycenie. To też najbardziej czasochłonna metoda estymacji ze wszystkich.

• Estymacja trzypunktowa (PERT) – dla każdego zadania wyznacza trzy wartości – optymistyczną, pesymistyczną i najbardziej prawdopodobną – po czym liczy średnią ważoną: (optymistyczna + 4 × najbardziej prawdopodobna + pesymistyczna) / 6. To nie tyle osobna metoda estymacji, co uzupełnienie pozostałych.

W TeaCode wycenę zawsze przygotowują dwie osoby, które faktycznie piszą kod – nasz CTO i ja. Jestem technicznym CEO, więc nie oceniam jej tylko z boku. Nie rozbijamy całego projektu na szczegółowy backlog zadań. Wyceniamy to, co naprawdę generuje koszt – każdą funkcję z osobna, plus architekturę, QA i zarządzanie projektem – i przypisujemy do każdego elementu konkretną liczbę. Tam, gdzie nie jesteśmy do końca pewni, na ile dokładnie coś wycenić, posługujemy się przedziałem godzinowym minimum–maximum. To coś innego niż probabilistyczne podejście, jakie opisał McConnell w „Software Estimation: Demystifying the Black Art" (2006) – w naszym przypadku dolna i górna granica przedziału nie wynikają ze ścisłych obliczeń statystycznych, chyba że przeprowadziliśmy wcześniej ich szczegółową kalibrację.

Jakie jest 5 poziomów szacowania kosztów oprogramowania? (Klasy AACE)

Zalecana Praktyka 18R-97 organizacji AACE International definiuje pięć klas wyceny – ale standard ten stworzono z myślą o wielkich inwestycjach przemysłowych, a nie o tworzeniu oprogramowania. To, jak zmieniają się przy tym widełki cenowe, pokazuje jedną ważną zasadę: wraz z lepszym zrozumieniem projektu, niepewność co do kosztów maleje. Poniżej korzystam z niej wyłącznie jako analogii, nie jako uznanego standardu wyceny software'u.

Źródło: AACE International RP 18R-97 (aktualna rewizja z 2020 roku). AACE uznaje te widełki za typowe, przy zachowaniu około 80% pewności. Pamiętaj jednak, że to tylko wskazówka – nie każda wycena musi idealnie mieścić się w tych ramach. Trafność konkretnej wyceny i tak trzeba przeanalizować pod kątem ryzyk na poziomie projektu, a same zakresy mogą się nakładać między klasami – powtarzalne zlecenie z Klasy 5 może wypaść lepiej niż projekt z Klasy 3 zbudowany na nowej, nieznanej technologii. Kolumna „Analogia software'owa TeaCode" to moja własna interpretacja, nie część oficjalnego standardu AACE 18R-97.

W naszej analogii dla TeaCode wstępna wycena software'owa odpowiada z grubsza Klasie 4–5, a Discovery pozwala zawęzić ją do przedziału bliższego Klasie 3 – czyli bardziej użytecznego przy podejmowaniu decyzji. 

Jak eksperci wyceniają projekty software’owe? Nasz 5-etapowy proces

Zanim wycena trafi do Twojej skrzynki, przechodzi u nas przez 5 etapów: rozmowę wstępną (tzw. scopingową), podczas której ustalamy zakres i wymagania projektowe, przegląd architektury przez CTO, wycenę element po elemencie, obsługę ryzyka i wreszcie konkretną propozycję działań, którą ostatecznie Ci wysyłamy. Oczywiście wycena ta jest jeszcze aktualizowana w trakcie realizacji projektu, bo proces developmentu ewoluuje przez cały cykl jego życia. Klasyczne metody, takie jak PERT czy bottom-up, są fundamentem naszego podejścia, ale pokażę Ci, jak konkretnie przekładają się na Twoją wycenę oraz opowiem o  sytuacjach, w których się pomyliliśmy w wyliczeniach.

Co dzieje się podczas rozmowy scopingowej?

Zwykle pierwszy na rozmowę wchodzi Mark, nasz Client Partnerships Manager – jego zadaniem jest wyciągnąć od Ciebie jak najwięcej informacji o projekcie, zanim padnie choćby słowo o cenie. Następnie, jeśli mamy na to przestrzeń, Michał (nasz CTO) albo ja do niej dołączamy. Nie pytamy tylko o to, co chcesz zbudować – ale też o to, o czym jeszcze nie pomyślałeś.

Pytania, jakie zwykle padają: kim są Twoi użytkownicy? Które integracje są absolutnie niezbędne? Przechodziłeś już przez fazę Discovery? Jaki masz budżet?

To ostatnie pytanie nie służy temu, żebyśmy dopasowali kwotę do Twojego budżetu – chodzi o sprawdzenie, czy zakres projektu i budżet w ogóle grają w tej samej lidze. To właśnie te informacje kształtują pierwszą wersję wyceny.

Dlaczego każdą wycenę sprawdza CTO albo CEO?

Przegląd techniczny robi nasz CTO, Michał Pierzchlewicz albo ja. Jestem CEO, ale nigdy nie przestałem być inżynierem – jestem tak samo techniczny jak Michał i sporo takich audytów robię osobiście. Tak czy inaczej, Twoją architekturę ocenia ktoś, kto faktycznie pisze kod i wie, jaka technologia pasuje do wymagań projektu, gdzie integracje sprawiają, że staje się bardziej złożony, jakie decyzje infrastrukturalne najbardziej wpłyną na ostateczny koszt.

Czasem projekt wydaje się prosty, ale w praktyce wymaga zaawansowanych technologii, takich jak przetwarzanie danych na żywo czy złożona architektura. Dzieje się tak w połowie naszych rozmów wstępnych. Ta różnica między wyobrażeniem o projekcie a technicznymi wyzwaniami to najczęstsza przyczyna, dla której ostateczny koszt różni się od początkowych szacunków.

Jak wyceniamy każdą część projektu?

Nasz CTO i ja wyceniamy projekt element po elemencie – każdą funkcję z osobna, a do tego architekturę, QA i zarządzanie – i dopiero potem łączymy te pojedyncze wyceny w jedną, ogólną. Celowo nie rozbijamy wszystkiego na szczegółowy backlog, zanim jeszcze podpiszesz umowę – on i tak się zmieni, gdy tylko ruszą prace nad projektem. Właśnie na tym etapie stosujemy naszą wewnętrzną klasyfikację funkcji na klasyczne, skomplikowane i niestandardowe (to nie jest standard branżowy): funkcjom klasycznym przypisujemy konkretną liczbę godzin, skomplikowanym – przedział godzinowy, a niestandardowym integracjom – szerokie widełki minimum-maximum.

To podejście zapożycza logikę szacowania oddolnego – wyceniamy projekt w częściach, a nie staramy się wycenić od razu całości – ale zatrzymuje się na tym, co faktycznie decyduje o koszcie: funkcjach, architekturze, QA i PM, a nie na każdym pojedynczym mikrozadaniu. Koszt pracy liczymy, mnożąc stawkę godzinową lub miesięczną danej osoby w zespole razy poświęcony czas. Dwie doświadczone osoby techniczne wyceniające rzeczywiste czynniki wpływające na koszt dają szybszy i trafniejszy wynik niż analiza setek ticketów, które i tak przesuną się gdzieś w okolicach drugiego sprintu. Zaangażowanie starszych developerów na tym etapie poprawia trafność wyceny, bo pozwala zweryfikować złożoność projektu, zanim ktokolwiek zacznie rozpisywać plan działania. W efekcie dostajesz kosztorys, który możesz prześledzić element po elemencie – a nie jedną zbiorczą kwotę, którą musisz przyjąć na wiarę.

Ta pierwsza wycena to zresztą sprawdzian naszego zrozumienia projektu – dzięki niej upewniamy się, że dobrze złapaliśmy, co właściwie budujesz. Kiedy już wyhaczymy, co pierwsza wersja kosztorysu przeoczyła, zwykle wysyłamy poprawioną, drugą wycenę. Ta, którą ostatecznie dostajesz na maila, rzadko kiedy jest naszym pierwszym trafem.

Jak podchodzimy do ryzyka i niepewności?

W zależności od tego, jak dużą część projektu stanowią funkcje niestandardowe i skomplikowane, doliczamy bufor związany z zarządzaniem ryzykiem – zwykle to 10–20% przy projektach o jasnych wymaganiach, więcej przy tych, które zaczynają się od samego pomysłu. Kiedy NIE dodajemy osobnego bufora? Gdy projekt przeszedł już przez naszą fazę Discovery, jego zakres jest dobrze zdefiniowany, a wybraną technologię wdrażaliśmy już setki razy.

Kiedy projekt faktycznie przekracza podane widełki, w moim doświadczeniu zawsze sprowadza się to do jednej z dwóch rzeczy: albo do architektury, którą trzeba było przebudować w trakcie, albo do zakresu, którego nie do końca zrozumieliśmy na starcie. Obie przyczyny w gruncie rzeczy zależą od tych samych dwóch zmiennych – jak dobrze poznaliśmy produkt przed wyceną i jak bardzo zmienił się po rozpoczęciu prac. Nad pierwszą pracujemy właśnie na rozmowie scopingowej i w trakcie Discovery: im lepiej rozumiemy projekt na starcie, tym bardziej precyzyjny przedział cenowy możemy podać. Druga to po prostu uczciwy koszt tworzenia oprogramowania – jeśli kierunek się znacząco zmienia i trzeba przebudować architekturę, to nie jest naciąganie kosztów, tylko konieczna poprawka, która staje się tym droższa, na im późniejszym etapie się pojawi. 

Przykład, gdzie się pomyliliśmy: w jednym z projektów wyceniliśmy integrację bramki płatniczej na 40 godzin, opierając się na dokumentacji dostawcy. Okazało się, że ta dokumentacja była dwie wersje w tyle za realnym API. Rzeczywisty czas pracy? 120 godzin.

Co jednak istotne: klient nie otrzymał nagle faktury na trzykrotność pierwotnej kwoty. Wliczony w wycenę bufor ryzyka pokrył większość dodatkowych kosztów, a skutkiem było jedynie dwutygodniowe przesunięcie harmonogramu prac. Na tym właśnie polega uczciwe szacowanie – to proces, który chroni Twój budżet przed niespodziewanymi wydatkami.

„Na tym właśnie polega uczciwe szacowanie – to proces, który chroni Twój budżet przed niespodziewanymi wydatkami."

A co, jeśli pełny zakres projektu przekracza budżet?

Standardowo zaczynamy od wyceny pełnego zakresu projektu. Jeśli jednak propozycja przekracza Twój budżet, nie upieramy się przy pierwotnym planie – przygotowujemy okrojoną wersję MVP i wyceniamy ją od nowa. Dzięki temu możesz podjąć świadomą decyzję, zamiast od razu angażować się w pełnowymiarowy rozwój produktu.

Kiedy proponujemy takie MVP, to nie jest zagranie marketingowe czy próba obniżenia ceny na siłę – to szczera rekomendacja. Większość projektów po prostu lepiej wychodzi na tym, że najpierw wypuszcza wersję testową, zbiera opinie od użytkowników, a dopiero potem inwestuje w dalszy rozwój produktu na podstawie zweryfikowanych założeń.

Cały proces zajmuje 2–5 dni roboczych, w zależności od złożoności projektu. Jeśli jakaś agencja przesyła Ci gotową wycenę w ciągu doby od pierwszej rozmowy, to znaczy, że albo bazuje na bardzo podobnym poprzednim projekcie, albo korzysta z modelu parametrycznego – albo po prostu zgaduje. Z mojego doświadczenia wynika, że zazwyczaj chodzi o to ostatnie, więc śmiało zapytaj, na czym oparta jest propozycja, którą otrzymałeś. 

Czy faza Discovery w ogóle się opłaca, zanim ruszy development?

Ustrukturyzowana faza Discovery to koszt poniesiony z góry – ale taki, który ma zastąpić zgadywanie w trakcie wyceny konkretami i co za tym idzie, jaśniejszym zakresem projektu, przemyślanymi decyzjami architektonicznymi i przetestowanymi założeniami, jeszcze zanim zacznie się właściwy development. Jeden z dostawców, Mobisoft, wycenia swoje Discovery na 15–30 tys. dolarów, twierdząc, że pozwala to zaoszczędzić 50–150 tys. dolarów na poprawkach (Mobisoft, 2026) – to dane podane przez samego dostawcę, a nie niezależny benchmark, więc traktuj je raczej jako punkt odniesienia niż gwarancję. W TeaCode nasze Discovery kosztuje zwykle 3–15 tys. dolarów, w zależności od tego, jak bardzo skomplikowany produkt chcesz zbudować. 

Rekomendujemy tę fazę praktycznie każdemu projektowi powyżej 30 tys. dolarów. Oto dlaczego.

Faza Discovery trwa u nas zwykle 1–3 tygodnie i angażuje niewielki, interdyscyplinarny zespół: stratega produktu, projektanta UX i tech leada. Warto pamiętać, że pogłębione badania, testy czy prace architektoniczne, mogą potrwać dłużej. Wracając jeszcze na chwilę do analogii z AACE – Discovery pozwala nam przejść od wstępnych wycen, często opartych jedynie na rozmowie telefonicznej, do bardziej precyzyjnego kosztorysu, który opiera się na zweryfikowanym zakresie prac, a nie czystych założeniach. To, jak dokładnie da się go zawęzić, zależy od projektu – warto przy tym pamiętać, że klasy AACE nie zostały stworzone z myślą o branży software'owej.

Zależnie od charakteru projektu, w ramach Discovery przygotowujemy: 

• profile użytkowników oparte na realnych danych rynkowych i zachowaniach klientów,
• krótkie opisy tego, co dokładnie ma robić dana funkcja,
• wireframe'y albo testowalny prototyp,
• propozycje udokumentowanych decyzji architektonicznych, które ograniczają ryzyko kosztownych poprawek,
• doprecyzowaną wycenę opartą na konkretnych ustaleniach, zamiast na domysłach.

Jest jednak coś, o czym większość agencji Ci nie powie: Discovery to też okazja, żeby przetestować przyszłego partnera technologicznego, zanim zaangażujesz się w projekt trwający pół roku. Pamiętaj jednak – zanim podpiszesz cokolwiek, upewnij się, że umowa daje Ci prawa własności lub licencji, których potrzebujesz, dostęp do edytowalnych plików źródłowych oraz możliwość przekazania rezultatów pracy innemu partnerowi. Jeśli to załatwisz, a współpraca się nie sprawdzi – bo komunikacja szwankuje, zespół nie rozumie Twojej wizji albo jakość zawodzi – możesz się wycofać, tracąc przy tym 3–15 tys. dolarów, a nie ponad 100 tysięcy.

To pułapka, w którą wpada więcej founderów, niż mogłoby się wydawać: rezygnują z Discovery, żeby zaoszczędzić 10 tysięcy, a potem wydają znacznie więcej na budowę niewłaściwego produktu – bo wymagania, na których się oparli, były tylko założeniami, a nie 

przemyślanymi decyzjami. Widziałem ten schemat wielokrotnie i to jeden z kosztowniejszych błędów, jakie może popełnić ktoś, kto zamawia software po raz pierwszy.

Pełną metodologię naszej fazy Discovery – co dokładnie w trakcie niej dostarczamy i ile to kosztuje – opisaliśmy w naszym przewodniku po całym procesie.

„Founderzy rezygnują z Discovery, żeby zaoszczędzić 10 tysięcy dolarów, a potem wydają znacznie więcej na budowę niewłaściwego produktu. Widziałem to wielokrotnie."

Jak porównywać wyceny od różnych firm software'owych?

Nie porównuj tylko kwot końcowych – przy wycenach godzinowych rozłóż je na stawkę i liczbę godzin osobno. Wycena na 60 tys. dolarów przy 800 godzinach to zupełnie inna historia niż te same 60 tys. dolarów przy 400 godzinach po 150 dolarów za godzinę. Ta sama cena, kompletnie inny produkt. (Przy kontrakcie fixed-price porównuje się już coś innego: zdefiniowany zakres projektu, wyłączenia, kamienie milowe, kryteria odbioru i zasady, określające kiedy cena w ogóle może się zmienić.)

Wiem, że to sporo do ogarnięcia naraz. Dlatego poniżej jest lista, którą sam przechodzę za każdym razem, gdy founder pokazuje mi konkurencyjne wyceny:

• Te same dane wejściowe powinny dawać porównywalny wynik. Wyceny przygotowane na podstawie tak różnych danych wejściowych – jak krótka, 30-minutowa rozmowa telefoniczna w jednym przypadku, a szczegółowy, dziesięciostronicowy brief w drugim – nie są ze sobą porównywalne. Zanim zaczniesz je zestawiać, upewnij się, że każda agencja pracowała na tych samych informacjach o Twoim projekcie.

• Doświadczenie deweloperów ma znaczenie. Ta sama funkcja może zostać wyceniona na 20 godzin pracy seniora albo 35 godzin pracy specjalisty mid-level – i to wcale nie jest naciąganie kosztów. Senior ma wyższą stawkę godzinową, ale w zależności od problemu, znajomości branży i struktury zespołu potrafi część pracy skończyć szybciej i z mniejszą liczbą poprawek. Zapytaj agencję, kto konkretnie jest przypisany do jakiej roli i jaką ma stawkę.

• Sprawdź, co dokładnie zawiera wycena. Czy obejmuje ona testy (QA), architekturę, konfigurację infrastruktury, panel administracyjny oraz logowanie i odzyskiwanie hasła? Te elementy nie muszą być rozpisane jako osobne pozycje – mogą być ukryte w kosztach poszczególnych funkcji lub wliczone w ogólną końcową kwotę – ale agencja powinna o nich wspomnieć i powiedzieć, jaką część wyceny stanowią. Jeśli jedna oferta jest o 30% tańsza, a wykonawca nie potrafi wyjaśnić, jak uwzględnił te kwestie, to sygnał ostrzegawczy. Istnieje duże ryzyko, że porównujesz nieporównywalne zakresy prac lub że coś ważnego pominięto. Taka „okazja” często staje się ukrytym kosztem, który zaskoczy Cię w trakcie pracy nad projektem. 

• Liczą się widełki, a nie pojedyncza kwota. Rzetelna wycena jest raczej podana w formie widełek – na przykład 70–90 tys. dolarów. Może to być też pojedyncza kwota, ale poparta udokumentowanymi założeniami, wyłączeniami i jasnym procesem wprowadzania zmian. Sucha kwota bez żadnego z tych elementów zwykle oznacza, że agencja zgaduje ostateczny koszt i po prostu się do tego nie przyznaje.
  ‍
  
• Doradztwo produktowe powinno być uwzględnione w wycenie. Dobra wycena zawiera rekomendacje: co uprościć, co odłożyć na później, co da się zrobić taniej innym sposobem. Jeśli dostajesz jedynie arkusz z godzinami i bez żadnej strategicznej myśli, to znak, że dostawcy nie zależy specjalnie na sukcesie Twojego produktu.

• Gotowość do przycięcia zakresu projektu do MVP to dobry znak. Agencja, która – zamiast bronić swojej wyceny – zaproponuje okrojoną wersję projektu do MVP, gdy pełny zakres wychodzi poza budżet, myśli o Twoim zwrocie z inwestycji, a nie tylko o swoim zarobku.

• Rozmowa to podstawa. Wycena to dopiero początek dyskusji, nie jej koniec. Dobry partner przeprowadzi Cię przez każdą pozycję, wyjaśni, jak rozłożone są zasoby i pokaże, czy project managerowie faktycznie na bieżąco pilnują zakresu projektu oraz zarządzają ryzykiem. Jeśli ktoś nie potrafi albo nie chce tego wytłumaczyć, to już samo w sobie mówi wiele o tym, jak będzie wyglądała komunikacja podczas prac nad projektem.

Więcej o wyborze odpowiedniego partnera technologicznego – w tym o czynnikach niezwiązanych bezpośrednio z ceną – znajdziesz w naszym tekście o podejściu skoncentrowanym na kliencie.

„Wycena na 60 tys. dolarów przy 800 godzinach po 75 dolarów za godzinę to zupełnie inna historia niż te same 60 tysięcy przy 400 godzinach po 150 dolarów. Ta sama kwota, kompletnie inny produkt."

Na jakie sygnały ostrzegawcze powinieneś zwrócić uwagę w wycenie, którą właśnie dostałeś?

Oto sześć sygnałów ostrzegawczych, na które zwracam uwagę, gdy founderzy pokazują mi wyceny od innych agencji:

• Brak QA w wycenie. Testowanie to nie jest opcja premium – to ono chroni użytkowników przed błędami w kodzie. QA może być osobną pozycją w budżecie, kosztem wliczonym w każdą funkcję lub zadaniem, za które odpowiadają deweloperzy. Jeśli dostawca nie potrafi wyjaśnić, czy i w jakim zakresie uwzględnił testy, nie zakładaj, że w ogóle zostały uwzględnione – ani że w ogóle da się porównać taką ofertę z innymi. Te kontrole są kluczowe dla jakości, bezpieczeństwa i zgodności z wymogami prawnymi. Pamiętaj, że błędy wykryte dopiero po wdrożeniu są dużo droższe w naprawie (mimo że koszt naprawy zależy od skali projektu), ponieważ często wymuszają przebudowę całych modułów, generują dodatkowe koszty wsparcia i nadszarpują zaufanie użytkowników. Przekonanie, że „poprawi się to później”, w praktyce rzadko ma pokrycie w rzeczywistości.

• Brak architektury w wycenie. Złożone aplikacje wymagają solidnego fundamentu – od projektu bazy danych, przez infrastrukturę, aż po przemyślaną architekturę. Prace te mogą zająć od kilku dni do nawet kilku tygodni, zależnie od stopnia skomplikowania projektu, wymogów bezpieczeństwa czy zaplanowanych integracji. Choć czasem realizuje się je w ramach pierwszych sprintów, muszą być uwzględnione w wycenie. Jeśli oferta od razu przechodzi do „Sprintu 1: budowa ekranu logowania", nie pokazując żadnych prac przygotowawczych, koniecznie zapytaj: gdzie są fundamenty?
  
  
• Brak wyjaśnienia niepewności. Gdy w projekcie jest sporo niewiadomych, w TeaCode doliczamy zazwyczaj 10–20% rezerwy. Jeżeli jednak zakres prac został dobrze określony podczas fazy Discovery, taka osobna rezerwa może nie być potrzebna. Sama wartość 0% nie jest jeszcze problemem. Czerwoną flagą jest sytuacja, w której agencja nie potrafi wytłumaczyć swoich założeń, określić poziomu pewności, wyjaśnić procesu wprowadzania zmian ani wskazać, kto pokryje koszty, gdy plan minie się z rzeczywistością.

• Zespół widmo. Zapis typu „4 deweloperów – 12 tygodni” niewiele mówi. Nie wiesz, kto jest liderem technicznym, czy w zespole jest dedykowany tester (QA) ani jakie doświadczenie mają poszczególne osoby. To kluczowe, bo od składu zespołu zależy nie tylko jakość, ale i końcowy koszt projektu – doświadczeni eksperci szybciej wyłapują ryzyka, co pozwala uniknąć kosztownych poprawek w przyszłości.

• Brak podziału na fazy. Jeśli dostajesz tylko jedną, ogólną kwotę, trudno Ci sprawdzić, czy wydatki idą w parze z postępami. Brak wyodrębnionych etapów prac to też mniej okazji, by zareagować, gdy projekt zaczyna zbaczać z kursu, a Ty tracisz jasny obraz tego, na co dokładnie wydajesz pieniądze.

• Brak planu na zredukowanie niewiadomych. Jeśli agencja nie proponuje sposobu na objaśnienie wszystkich aspektów projektu przed podpisaniem umowy – np. warsztatu Discovery, analizy technicznej czy prototypowania – to poważny sygnał ostrzegawczy (wyjątkiem są bardzo proste, powtarzalne projekty). Dodatkowo, w kosztorysie muszą się znaleźć takie elementy jak logowanie, odzyskiwanie hasła czy panel administracyjny.
  

Jak to wygląda w praktyce: founder dostaje trzy wyceny – 60, 90 i 120 tysięcy dolarów – i zakłada, że najtańsza jest po prostu najkorzystniejszą ofertą. Gdy jednak przyjrzę się tej za 60 tysięcy, od razu widzę, że brakuje w niej QA, nie ma mowy o architekturze, zakłada pracę jednego dewelopera mid-level i nie uwzględnia zarządzania ryzykiem. To wszystko może w efekcie podnieść koszty na późniejszym etapie. Ta za 90 tysięcy pokrywa wszystko, czego brakuje w tej za 60. Ta za 120 tysięcy dorzuca jeszcze doradztwo produktowe i fazę Discovery. Na podstawie tego, co widzę, to właśnie wycena na 90 tysięcy ma największe szanse faktycznie dowieźć działający produkt – ta za 60 tysięcy jest tania, bo po prostu jest niedokładna.

„Jeśli agencja nie potrafi powiedzieć, gdzie w wycenie mieszczą się QA i architektura – ani jak radzi sobie z niepewnością – masz przed sobą ofertę sprzedażową."

Jak wygląda naprawdę dobra, finalna wycena?

Przy zaangażowaniu rozliczanym godzinowo dobra wycena jest podzielona na pozycje i wyraźne fazy oraz mieści się w konkretnych widełkach: uwzględnia stawki godzinowe dla każdego z zespołu, QA, architekturę i niepewność, podaje przedział kwotowy zamiast ogólnej sumy i zwykle proponuje też okrojoną alternatywę projektu. (Przy umowie fixed-price dobra propozycja może nie ujawniać stawek ani liczby godzin, ale wciąż powinna jasno określać zakres, wyłączenia, kamienie milowe, kryteria odbioru i zasady zmian.) Większość founderów nigdy takiej wyceny nie widziała, więc nie wiedzą, z czym w ogóle porównywać to, co dostali. Poniżej znajdziesz proste rozróżnienie:

❌ Oferta sprzedażowa udająca wycenę:

„Aplikacja webowa – 12 tygodni – 60 000 dolarów. Zespół: 4 devów."

Jeśli w wycenie brakuje testów (QA), architektury, nazw stanowisk osób z zespołu, konkretnych widełek cenowych, podziału na etapy czy alternatywnych rozwiązań – nie masz przed sobą rzetelnej wyceny, lecz typową ofertę sprzedażową stworzoną tylko po to, byś podpisał umowę.

‍

✅ Wycena, która ma faktycznie dowieźć produkt:

„Aplikacja webowa – Faza 1 (MVP): 10–14 tygodni – 72–92 tys. dolarów. Zespół: 1 tech lead (65 USD/h), 2 senior devów (55 USD/h), 1 inżynier QA (45 USD/h) zaangażowany częściowo – łącznie to około 1250–1600 szacowanych godzin zespołu przy uśrednionej stawce około 57 USD/h. Przedział wyceny uwzględnia 15% rezerwy; w rozliczeniu T&M płacisz za faktycznie przepracowane godziny. W zakres wchodzą: dwutygodniowa konfiguracja architektury, przepływy uwierzytelniania (logowanie, rejestracja, odzyskiwanie hasła), panel administracyjny. Założenia spisane. Ryzyka oznaczone. Alternatywa: okrojone MVP – 48–58 tys. dolarów."

Ta druga wersja może wydawać się na początku mniej czytelna i trudniejsza do wrzucenia w Excela, ale o to właśnie chodzi. Tworzenie oprogramowania to złożony proces. Każda wycena, która upraszcza go za bardzo, tylko ukrywa przed Tobą rzeczywistość, zamiast pomagać w lepszym zarządzaniu projektem. W modelu godzinowym lub T&M powinieneś mieć jasny wgląd w to, za co płacisz – na podstawie stawek, godzin i założeń powinieneś być w stanie samodzielnie przeliczyć całkowity koszt. W modelu fixed-price agencja nie musi pokazywać Ci szczegółowego cennika. Jednak musisz mieć jasność co do zakresu prac, wyłączeń, terminów realizacji i zasad wprowadzania zmian.

Co warto przynieść na pierwsze spotkanie z agencją?

To temat, który pomija większość poradników o wycenach – a to tutaj następuje przejście od koncepcji do budowy. Kiedy już przeanalizujesz wyceny, wybierzesz partnera i jesteś gotowy zacząć działać – przygotuj przed spotkaniem te 5 rzeczy, które potrafią realnie skrócić cały proces scopingu:

• Dane o klientach – kim są, ile płacili (albo ile byliby skłonni zapłacić), o co wielokrotnie prosili. Jeśli przeprowadziłeś jakąkolwiek walidację – concierge MVP, landing page, testy beta – przynieś konkretne raporty.

• Dokumentację procesu – jak dokładnie wygląda ścieżka użytkownika, krok po kroku, ekran po ekranie. Zrzuty ekranu, notatki, logi czasowe. Im bardziej chaotyczne, tym lepiej.

• Dziennik problemów – każde zgłoszenie klienta, każdy moment zamieszania, każde „a czy da się jeszcze zrobić X?". To właśnie staje się Twoją specyfikacją produktu – opartą na opiniach klientów, a nie Twoich domysłach.

• Priorytetyzację funkcji – co jest niezbędne, a co miłym dodatkiem, uszeregowane według realnej częstotliwości użycia albo zapotrzebowania klientów, a nie przeczucia. Bądź tu bezwzględny: to właśnie funkcje wycięte z pierwszej wersji bardzo często sprawiają, że projekt mieści się w budżecie.

• Realistyczne oczekiwania co do budżetu i harmonogramu – bez zawyżania. Sprawdź nasz przewodnik po kosztach tworzenia oprogramowania, żeby poznać aktualne widełki dla różnych typów projektów oraz nasz audyt kosztów MVP z rozbiciem na poszczególne fazy.

Taki zestaw jest wart więcej niż jakikolwiek dokument techniczny spisany w oderwaniu od realiów. Kiedy founder przychodzi do nas ze spisanymi problemami i danymi o klientach, jesteśmy w stanie wycenić projekt dużo szybciej – bo cała część związana ze zgadywaniem jest już za nami.

„Kiedy founder przychodzi do nas ze spisanymi problemami i danymi o klientach, jesteśmy w stanie wycenić projekt dużo szybciej – bo cała część związana ze zgadywaniem jest już za nami."

Chcesz uzyskać przejrzystą wycenę?

Teraz już wiesz, czego szukać – i czego lepiej unikać.

Większość agencji poprzestaje na podaniu jednej, zbiorczej kwoty. W TeaCode dokładnie pokazujemy, z czego ona wynika: zobaczysz rozbicie na funkcje, architekturę, testy (QA) i zarządzanie projektem (PM), stawki godzinowe poszczególnych osób w zespole oraz ocenę ryzyka. A jeśli pełny zakres przekracza Twój budżet, przygotujemy też lżejszą wersję projektu w postaci MVP.

Wycena z TeaCode to pewność, że wiesz, na czym stoisz. Zero ukrytych opłat. Zero zaskakujących faktur. Zero „ogarniemy to po drodze".

Uzyskaj przejrzystą wycenę dla swojego projektu →