Jak wybrać software house po złym doświadczeniu: 7 pytań zanim podpiszesz umowę

Na początek podpisałeś umowę. Software house obiecał MVP w 12 tygodni, 200 tysięcy złotych fixed price. „Jesteśmy najlepsi w branży, sprawdź nasze portfolio.” Sprawdziłeś. Logo znanych marek. Ładne screeny. Brak konkretnych liczb.

Po trzech miesiącach: „scope się rozszerzył, trzeba dopłacić 50 tysięcy.” Zgodziłeś się, ponieważ masz już zainwestowane pieniądze i czas. W szóstym miesiącu: „trochę się opóźniliśmy, ale zaraz będzie demo.” Demo to mockup w Figmie. Dziewiąty miesiąc: „senior odszedł z firmy, zastępujemy go juniorem.” Rok później masz fakturę za 80 procent budżetu. Oraz puste Jira. Do tego połowę produktu, który nie działa na produkcji. Dlatego stoisz z pustym Jira i pełną fakturą.

Otóż ten artykuł jest dla Ciebie. Przede wszystkim nie po to, żeby Ci powiedzieć „wybierz JSON Crew”. Ponadto po to, żeby pokazać 7 pytań, które powinieneś zadać KAŻDEMU software house’owi PRZED podpisaniem umowy. Mianowicie zadanie tych 7 pytań oszczędzi Ci 200 tysięcy złotych i rok życia.

Jak wybrać software house: problem nie jest oni, problem jest brak pytań które zadałeś

Mianowicie badania McKinsey pokazują, że duże projekty IT (powyżej 15 milionów dolarów) są średnio 45 procent over budget i 7 procent over time, natomiast dostarczają 56 procent wartości biznesowej którą obiecały. Ponadto 75 procent respondentów IT w badaniu Geneca uważa, że ich projekty są „skazane na porażkę od początku.”

Otóż te statystyki nie są przypadkiem. Natomiast są wynikiem powtarzalnego wzorca: klient podpisuje umowę bez zadania 7 kluczowych pytań. Dlatego SH uczy się po latach, że klient nie pyta, więc nie odpowiada. Z kolei dobry software house odpowiada na te pytania PRZED pytaniem, ponieważ sam je zadaje sobie na rozmowa wstępna.

Jakie pytania zadać software house? 7 pytań przed podpisaniem umowy

Pytanie 1: Pokaż mi 3 projekty z LICZBAMI, nie z obietnicami

Przede wszystkim najtrudniejsze pytanie dla przeciętnego software house. Ponieważ większość portfolio to zrzuty ekranu i logo klientów. Brak metryk. Żadnego before/after. Zero cytatów z liczbami.

Red flag: „Nasz zespół wdrożył 200+ projektów.” Bez żadnej konkretnej historii. Bez konkretnego klienta gotowego potwierdzić wyniki. Bez liczb.

Green flag: case study z przed/po + konkretnymi liczbami + cytatem klienta. Na przykład: „Akpil: 136-stronicowy cennik PDF → interaktywny konfigurator 3D. Wycena z 3 dni do 15 minut. Handlowiec spędza 60 procent mniej czasu na admin.” Z kolei cytat klienta: „Wycena w minutach, nie w dniach. Handlowiec wybiera, system liczy.”

Mianowicie pytanie follow-up: „Mogę zadzwonić do tego klienta?” Dobry software house bez zająknięcia poda numer. Natomiast zły SH powie: „Klient nie udziela referencji.” Albo: „Prześlemy Ci pisemną referencję.” To red flag.

Pytanie 2: Kto KONKRETNIE będzie pracował nad moim projektem?

Otóż klasyczny trick w sprzedaży SH: na spotkaniu handlowym pokazują seniora z 15-letnim doświadczeniem. Podpisujesz umowę. W poniedziałek zaczyna pracę junior z 6-miesięcznym stażem. Senior był „przedstawicielem podczas sprzedaży.”

Red flag: „Nasz zespół ma 50 inżynierów”, bez konkretnych imion, bez LinkedIn, bez portfolio osobistego osób, które faktycznie będą kodować Twój projekt.

Green flag: konkretne imiona, role, LinkedIn profile, portfolio indywidualne. Ponadto jasno określone kto jest tech leadem, kto developerem, kto designerem. Dodatkowo jeden dedykowany PM/product owner po stronie SH przez cały czas projektu.

Przede wszystkim Standish CHAOS Report wskazuje ludzi jako przyczynę numer 1 failure projektów IT. Brak kompetencji, rotacja zespołu w trakcie projektu, niedopasowanie do wymagań, to zabija więcej projektów niż zła architektura.

Pytanie 3: Jak wygląda PIERWSZY TYDZIEŃ po podpisaniu umowy?

Mianowicie to jest pytanie diagnostyczne numer 1. Dlatego że odpowiedź ujawnia metodologię pracy SH.

Red flag: „Zaczynamy kodować od razu, żeby jak najszybciej dostarczyć MVP!” To brzmi dobrze, jednak jest katastrofą. Brak rozmowa wstępna oznacza brak zrozumienia procesu, brak wywiadu z użytkownikami, brak mapy wymagań. W rezultacie kod bez fundamentu to kod do przepisania za 3 miesiące.

Green flag: rozmowa wstępna plus audit przez pierwsze 3-7 dni. Warsztat z Twoim zespołem. Mapa procesu „as-is” i „to-be”. User stories. Wireframe lub klikalny mockup PRZED jedną linijką kodu produkcyjnego.

Z kolei badania Standish CHAOS pokazują, że projekty z formalnym rozmowa wstępna mają 2x wyższy success rate. Ponadto to inwestycja 10 procent czasu projektu, która oszczędza 50 procent kosztów scope creep.

Pytanie 4: Co jest W CENIE, a co nie jest?

Otóż klasyczna pułapka: wycena „od 200 tysięcy złotych” bez specyfikacji. Podpisujesz. W miesiącu 2 dostajesz maila: „Authentication nie było w zakresie, dopłata 15 tysięcy.” W miesiącu 4: „Integracja z Twoim ERP nie była w zakresie, dopłata 30 tysięcy.” Natomiast po 6 miesiącach masz 280 tysięcy zamiast 200.

Red flag: wycena bez szczegółowej listy deliverables. „Zrobimy Ci aplikację”, bez specyfikacji co wchodzi, co nie.

Green flag: jasna lista deliverables per faza. Lista out of scope (co jest na pewno NIE wliczone). Cennik change requests. Jasna polityka: „jeśli pojawi się nowy wymóg, wycenimy go osobno PRZED wykonaniem, z Twoją akceptacją.”

Ponadto dobry SH stosuje Fixed Price na start projektu (MVP, jasny zakres), a dopiero w fazie 2 przechodzi na Time & Materials (iteracje, feedback rynkowy). Mianowicie to jest model custom MVP, który chroni Cię przed scope creep na starcie.

Pytanie 5: Co się stanie gdy przekroczymy budżet?

Otóż to jest pytanie, którego boi się każdy przeciętny SH. Natomiast dobry SH ma gotową odpowiedź.

Red flag: „Nie powinno się to zdarzyć” albo „zobaczymy jak będzie.” Brak planu B oznacza, że gdy scope się rozszerzy (a rozszerzy się), Ty za to zapłacisz bez dyskusji.

Green flag: jasna polityka change requests: jak zgłaszać, ile kosztują, kto autoryzuje. Buffer 10-20 procent w wycenie na nieprzewidziane. Fixed Price z jasnym zakresem oznacza: scope creep = osobna wycena PRZED wykonaniem. Ponadto milestones płatności co 2-4 tygodnie (nie na końcu projektu), żebyś mógł zatrzymać współpracę bez tracenia wszystkiego.

Dlatego pytanie follow-up: „Czy jeśli coś pójdzie nie tak po pierwszym miesiącu, mogę odejść bez płacenia za cały projekt?” Jeśli odpowiedź brzmi „nie”, to red flag. Z kolei dobry SH oferuje milestones gating plus IP transfer w każdym momencie.

Pytanie 6: Mogę zobaczyć DZIAŁAJĄCY produkt po 2 tygodniach?

Mianowicie to jest test czy SH robi agile czy waterfall przebrany za agile.

Red flag: „Pokażemy gotowy produkt po 3 miesiącach.” Albo: „Robimy sprinty, ale demo będzie na koniec.” To nie jest agile. To jest waterfall w agile clothing.

Green flag: klikalny prototyp po tygodniu 1-2 (mockup lub Storybook komponenty). Deployowany MVP po 4-6 tygodniach (nawet jeśli niekompletny). Demo co 1-2 tygodnie z Twoim zespołem. Ponadto Ty masz dostęp do repo od dnia 1 i widzisz commity codziennie.

W związku z tym badania Standish CHAOS pokazują, że iterative delivery z feedback loops daje 3 razy wyższy success rate niż waterfall. Natomiast jeśli SH chce Ci pokazać produkt dopiero na końcu, to znak, że boi się Twojego feedbacku w trakcie.

Pytanie 7: Kto jest WŁAŚCICIELEM kodu, gdy odejdę?

Otóż to jest pytanie, które 90 procent firm zadaje za późno. Zazwyczaj po tym jak się pokłócili z SH i chcą przenieść projekt gdzie indziej.

Red flag: „Kod jest na naszym GitHubie, prześlemy go po zakończeniu projektu.” To vendor lock-in. Jeśli SH trzyma kod jako zakładnika, masz problem od dnia 1.

Green flag: klient ma dostęp do repo od dnia 1. IP kod = własność klienta zgodnie z umową (transfer po każdej fakturze). Dokumentacja techniczna po zakończeniu fazy. Stack open source (React, Node, PostgreSQL), nie proprietary framework dostawcy.

Dodatkowo pytanie follow-up: „Jaki jest Twój stack technologiczny i dlaczego?” Jeśli odpowiedź brzmi: „Używamy naszego własnego frameworka”, uciekaj. Mianowicie żaden z Twoich przyszłych deweloperów nie będzie go znał. Dlatego dobry SH używa mainstream stacku open source (Next.js, React, Node, TypeScript, PostgreSQL), znanego milionom developerów na świecie.

Jakie są red flags software house? 7 sygnałów ostrzegawczych

Drzewo decyzji: kiedy Fixed Price, kiedy T&M, kiedy nie robić custom

Scenariusz 1: Masz jasny zakres i deadline. Fixed Price.
Mianowicie MVP z jasno zdefiniowanym zakresem (np. konfigurator produktowy 5-krokowy z dwoma integracjami) = Fixed Price. Cena zamknięta, termin zamknięty, scope creep = osobna wycena. Dlatego chroni Cię przed niespodziankami. Typowy MVP: 30-90 tysięcy PLN, 8 tygodni (przykład ile kosztuje konfigurator).

Scenariusz 2: Zakres płynny, potrzeba iteracji. Time & Materials po MVP.
Otóż po dostarczeniu MVP wchodzisz w fazę 2: iteracje oparte na feedback rynkowym. W takim przypadku T&M ma sens, ponieważ nie wiesz jeszcze co chcesz rozwijać. Jednak zawsze z szacowanym budżetem miesięcznym (np. 20-40k PLN/mies) i jasnym czym się zajmujecie w danym sprincie.

Scenariusz 3: Nie potrzebujesz custom, wystarczy SaaS. Kup gotowca.
Z kolei jeśli Twój proces jest standardowy (CRM, ofertowanie, projekty), rozważ najpierw gotowe rozwiązania. Ponadto pełen ranking: ranking CRM 2026 plus ranking konfiguratorów 2026. Custom software house ma sens tylko gdy SaaS Ci nie starcza.

Scenariusz 4: Masz złe doświadczenie, boisz się powtórzyć. Rozmowa wstępna audit.
Natomiast zamiast podpisywać duży kontrakt, zacznij od rozmowa wstępna/audit (3-5 dni, 3-10k PLN). Zmapujcie proces, zdefiniujcie MVP, zróbcie wycenę. W rezultacie dostajesz dokument, który możesz zabrać do innego SH. Dlatego dobry SH nie boi się że Ty zabierzesz rozmowa wstępna do konkurencji. Zły SH boi się i dlatego nie proponuje tego modelu.

FAQ: pytania które dostajemy po złym doświadczeniu

Ile powinien realnie kosztować MVP w 2026?

Mianowicie dla polskiego rynku: 30-90 tysięcy PLN za custom MVP (8 tygodni, zespół 2-4 osoby), 100-300 tysięcy PLN za mid-market SH, 200-500 tysięcy PLN za enterprise SH. Natomiast jeśli ktoś oferuje MVP za 15 tysięcy PLN, uciekaj. To albo junior fresh po bootcampie, albo offshore bez kontroli, albo template WordPress zamiast custom. Pełny breakdown: ile kosztuje konfigurator ofertowy.

Fixed Price czy Time & Materials: co lepsze?

Otóż zawsze zaczynaj od Fixed Price na MVP. Dlatego że FP chroni Cię przed scope creep i daje jasny termin. Mianowicie dopiero po dostarczeniu MVP przechodź na T&M dla fazy 2 (iteracje). Natomiast SH, który od razu proponuje tylko T&M bez estimate, traktuje Twój budżet jak bilet otwarty. Czerwona flaga.

Jak sprawdzić software house przed podpisaniem umowy?

Przede wszystkim 5 kroków. Pierwszy: Clutch.co/GoodFirms plus opinie Google. Drugi: LinkedIn zespołu (sprawdź konkretnych ludzi którzy będą pracować). Następnie zadaj 7 pytań z tego artykułu i oceń odpowiedzi. Czwarty krok: poproś o 2-3 numery telefonów do byłych klientów i zadzwoń. Ostatni: zacznij od małego projektu (rozmowa wstępna audit 3-5 dni), nie od dużego kontraktu od razu.

Co robić gdy projekt się już sypie?

Otóż trzy kroki. Najpierw dokumentuj wszystko (emaile, zmiany zakresu, opóźnienia), potrzebne jeśli będzie spór. Następnie zwołaj meeting z tech leadem SH i przedstaw konkretne obawy plus deadline naprawy. Z kolei jeśli po 2 tygodniach brak poprawy, rozważ przeniesienie projektu. Ponadto przed przeniesieniem upewnij się, że masz dostęp do repo i dokumentacji. Mianowicie umowa powinna to gwarantować, jeśli nie gwarantuje, to sama w sobie jest red flag na następny raz.

Jak znaleźć software house dla konfigurowalnego produktu?

Mianowicie dla konfigurowalnych produktów (rekuperacja, OZE, HVAC, budowlanka, maszyny, meble custom) potrzebujesz SH który wdrożył minimum 3 podobne projekty. Ponadto powinien znać branżę (rozumieć BOM, walidację techniczną, dotacje OZE, KSeF). W rezultacie pełny ranking polskich SH z konfiguratorami: najlepsze konfiguratory produktowe 2026 (zwłaszcza Tier 5, rynek polski).

Co dalej

Przede wszystkim wybór software house po złym doświadczeniu to nie jest kwestia znalezienia „tego najlepszego”. Natomiast to jest kwestia zadania właściwych pytań ZANIM podpiszesz umowę. Mianowicie 7 pytań z tego artykułu odsieje 80 procent złych opcji.

Z kolei jeśli szukasz software house do konfiguratora produktowego albo automatyzacji ofertowania, napisz do nas. Otóż zadajemy sobie sami te 7 pytań, odpowiedzi są gotowe PRZED Twoim pytaniem. Ponadto zobacz case studies: Akpil (konfigurator 3D dla maszyn rolniczych), Knieja (konfigurator broni myśliwskiej z walidacją techniczną), Blachodach (konfigurator ogrodzeń i dachów plus spacer wirtualny). Dlatego nie gadamy, pokazujemy.

Najczęstsze pytania