[Spis treści]Pokaż spis treści
Oceniliśmy ~200 vendorów dla naszych produktów. Sami byliśmy oceniani ~150 razy. Po 10 latach: kodowałem dla zespołów i kupowałem od zespołów. Przepaść między good-on-paper a good-in-reality jest ogromna.
Ten framework to nie akademicka lista. Wypadł z konkretnych projektów, w których coś poszło nie tak albo poszło lepiej, niż ktokolwiek się spodziewał. Każde kryterium ma powód istnienia i sposób weryfikacji. Pełną ofertę zobaczysz w przeglądzie usług, realne wdrożenia w realizacjach.
Scorecard wyboru software house — 10 kryteriów
Te dziesięć kryteriów biorą się z porażek, nie z teorii. Kryterium 3 (skład zespołu) — junior-only zespół nam padł na projekcie za 280k PLN. Kryterium 6 (rescue) — każdy dojrzały shop ma za sobą projekty, które musiał reanimować. Jeśli vendor nie ma takich historii, sprzedaje Ci tylko wersję wygładzoną.
Jak oceniać portfolio vendora?
Vendor pokazuje 5 case studies, wszystkie sukcesy — czerwone światło. Pokazuje jedną porażkę i tłumaczy, jak ją naprawił — wtedy słuchasz. To jedyna miara, która działa.
Poproś o 3-5 case studies z Twojej branży lub o porównywalnej złożoności. Nie prezentacje, tylko konkrety z metrykami. Ile trwał projekt? Jaki był budżet? Co poszło nie tak? Dorzuć drugi test: poproś o kontakt do klienta z projektu, który miał problemy. Odmowa to dyskwalifikacja.
2. Proces wytwórczy — powtarzalność ponad kreatywność
Zapytaj: jak wygląda Wasz typowy Sprint? Kto pełni rolę Product Ownera? Jak raportujecie postępy? Jak obsługujecie change requesty? Dojrzały software house opisuje swój proces w 5 minut, bo jest powtarzalny. Zły mówi “dostosowujemy się do klienta”, co najczęściej oznacza brak procesu.
Sprawdź, czy mają zdefiniowaną Definition of Done, code review, CI/CD pipeline od dnia pierwszego. To higiena, nie luksus. W 2026 brak automatycznego testowania i deploymentu to sygnał, że firma utknęła w 2015.
3. Zespół — poznaj ludzi, nie slajdy
Na etapie sprzedaży rozmawiasz z handlowcem i senior architektem. Ale kto faktycznie napisze Twój kod? Żądaj poznania zespołu przypisanego do projektu. Sprawdź proporcję seniorów do juniorów. Junior-only zespół z jednym senior-mentorem to przepis na katastrofę powyżej 500 roboczogodzin — przetestowaliśmy to na własnej skórze i kosztowało nas ćwierć miliona.
Zapytaj o rotację. Powyżej 25% rocznie oznacza, że Twój zespół zmieni się w trakcie projektu. Każda zmiana programisty to 2-4 tygodnie utraconej produktywności i wiedza kontekstowa wycieka razem z nim.
4. Komunikacja — częstotliwość i narzędzia
Pozornie drobne kwestie generują 80% frustracji w projektach IT. Minimalny standard: codzienny status asynchroniczny, tygodniowy call z demo, czas reakcji poniżej 4 godzin roboczych.
Powiedzieliśmy vendorowi: piątek 16:00, pytanie techniczne. Odpowiedź we wtorek. Ta delta zabiła deal. Jeden test komunikacji jest wart więcej niż dziesięć obietnic w ofercie.
5. Podejście do porażek — test dojrzałości
Zapytaj wprost: opowiedzcie o projekcie, który się nie udał. Co poszło nie tak? Co zmieniliście w procesie po tej porażce? Firma, która twierdzi, że nigdy nie miała nieudanego projektu, kłamie albo nie ma wystarczającego doświadczenia. Szukaj partnerów, którzy mówią o porażkach otwarcie — to oznacza kulturę uczenia się, nie marketingu.
6. Rescue capability — umiejętność ratowania
Czy firma ma doświadczenie w przejmowaniu projektów po innych zespołach? Rescue mission wymaga szybkiego audytu, stabilizacji i refaktoryzacji. Te kompetencje przydają się też w Twoim projekcie, gdy pojawią się nieprzewidziane problemy, a pojawią się.
W Do More Soft rescue missions to około 30% projektów. Każdy z nich nauczył nas więcej o inżynierii oprogramowania niż dziesięć projektów greenfield. Ta wiedza przekłada się bezpośrednio na jakość nowych wdrożeń.
7. Transparentność cenowa
Uczciwość w wycenie oznacza wyjaśnienie, jak ta kwota została skalkulowana. Ile godzin na poszczególne moduły? Jaki bufor na ryzyko? Co jest w scope, a co nie? Firmy podające jedną liczbę bez rozbicia robią wycenę “na oko” albo świadomie ukrywają koszty. Przy poważnych projektach zacznij od formalnego audytu i konsultingu — strukturyzuje wycenę i eliminuje niespodzianki.
8. Dopasowanie technologiczne
Nie chodzi o React vs Vue. Chodzi o to, czy stack pasuje do Twojego kontekstu: istniejącej infrastruktury, kompetencji Twojego zespołu, długoterminowych planów. Firma forsująca swoją ulubioną technologię bez analizy Twoich potrzeb rozwiązuje swój problem, nie Twój.
Zapytaj: dlaczego wybralibyście technologię X dla mojego projektu? Odpowiedź “bo w tym jesteśmy najlepsi” to wyjście z gry. Prawidłowa zawiera analizę Twoich wymagań, ograniczeń i planów rozwoju.
9. Dopasowanie kulturowe
Kultura organizacyjna software house’u wpływa na każdy aspekt współpracy. Firma z kulturą “yes-man” nigdy nie powie Ci, że Twój pomysł jest zły. Firma z kulturą inżynierską powie i zaproponuje lepsze rozwiązanie. Szukaj partnerów, którzy potrafią powiedzieć “nie” i uzasadnić dlaczego. To jest wartość, za którą płacisz.
10. Umowa — zabezpieczenie, nie formalność
IP, NDA, gwarancje, warunki wypowiedzenia, escrow kodu, SLA na support po wdrożeniu. Te kwestie muszą być jasne przed podpisaniem. Nie zostawiaj ich prawnikowi na koniec. Dobra umowa chroni obie strony i definiuje oczekiwania. Szczególnie klauzula exit — co się stanie, jeśli współpraca nie wyjdzie? Czy dostaniesz kod źródłowy, dokumentację i knowledge transfer?
Jakie pytania zadać software house przed umową?
Vendor mówił, że ma Definition of Done. Pokazali listę w Jirze. Nikt nie czytał jej od 3 miesięcy. To cargo cult. Zadaj pytania, które weryfikują praktykę, nie deklarację: kiedy ostatnio zaktualizowaliście DoD? Pokażcie commit z code review, w którym senior odrzucił PR juniora. Pokażcie incydent produkcyjny i post-mortem.
Framework w praktyce
Oceń każde kryterium w skali 1-5. Suma poniżej 35 — szukaj dalej. Jedno kryterium z oceną 1 to deal-breaker, niezależnie od sumy. Najczęstsze błędy: wybór najtańszej oferty (płacisz podwójnie za rescue), wybór największej firmy (Twój projekt jest dla nich nieistotny), wybór na podstawie prezentacji (slajdy nie piszą kodu).
Ten framework to narzędzie diagnostyczne. Widzisz red flags wcześnie — oszczędzasz miesiące. Ignorujesz, bo propozycja ładna — masz to, na co zasłużyłeś.
Chcesz scorecard w PDF/Excel? Zapisz się na checklist poniżej, wysyłamy edytowalny szablon z 10 kryteriami i polami na oferty trzech firm obok siebie. Jeśli chcesz, żebyśmy sami ocenili się tym frameworkiem — napisz to wprost. Postawisz nam 1 w jakimkolwiek kryterium, powiemy Ci, jak to poprawimy, albo polecimy konkurenta, który jest w tym lepszy od nas.
FAQ
Jakie 10 kryteriów wyboru software house? Portfolio (case studies z porażkami), proces wytwórczy (powtarzalność), zespół (skład senior/junior, rotacja), komunikacja (czas reakcji), podejście do porażek, rescue capability, transparentność cenowa, dopasowanie technologiczne, dopasowanie kulturowe, umowa (exit clause).
Jak oceniać portfolio vendora? 5 sukcesów bez ani jednej porażki to red flag. Wymagaj kontaktu do klienta z projektu, który miał problemy. Sprawdź metryki: czas, budżet, scope creep, retencja zespołu.
Co to red flags przy wyborze partnera developerskiego? Brak procesu (“dostosowujemy się do klienta”), junior-only zespół, rotacja powyżej 25% rocznie, wycena jedną liczbą bez rozbicia, kultura “yes-man”, odmowa kontaktu do trudnych klientów, brak klauzuli exit w umowie.