Nie wybieraj software house’u do MVP tylko na podstawie obietnic. Zamiast tego ustaw test: pilot sprint (1–2 tygodnie) oraz dowody procesu i jakości w repo, bo MVP służy „validated learning” i ma dawać decyzje oparte o dane. Dobrym pomysłem będzie również zapoznanie się z portfolio danego vendora.

Najważniejsze wnioski z artykułu

• Najpierw zdefiniuj cel uczenia się i minimalny flow, inaczej porównujesz slajdy zamiast ryzyka.
• Porównuj oferty przez te same osie: kontrola (repo/IP), proces (demo/DoD), jakość (review/testy), budżet (model).
• Wymagaj pilota 1–2 tygodnie i oceniaj dowody z repo, nie deklaracje.
• Zabezpiecz exit i przenoszalność, bo lock-in zaczyna się od braku repo i dokumentacji.
• Opinie i certyfikaty są sygnałem, ale decyzję opieraj na twardych artefaktach i regułach odrzucenia.

Dlaczego wybór software house do MVP wygląda inaczej niż do “normalnego projektu”?

MVP ma sens tylko wtedy, gdy maksymalizuje validated learning przy minimalnym wysiłku, więc wybór wykonawcy jest wyborem procesu iteracji. Plan etapów MVP bywa opisywany jako 12–16 tygodni pracy, ale to przykład procesu, nie norma rynkowa. W rozmowach z founderami często wraca temat procesów i transparentności, dlatego warto porównywać deklaracje z tym, jak firmy opisują swój sposób pracy np. Selleo.

Jeśli potraktujesz MVP jak „pierwszą wersję produktu”, szybko rośnie lista funkcji. Lista funkcji nie jest miarą postępu MVP, bo postępem jest decyzja oparta o feedback. To brzmi banalnie, ale MVP ma jeden cel: nauczyć się czegoś, co zmienia kierunek. Bez tego porównasz oferty po liczbie ekranów i nazwach technologii.

Discovery nie jest ozdobą procesu. Discovery jest ubezpieczeniem przed złym zakresem, bo ujawnia założenia i ryzyka. Po discovery powinny istnieć artefakty, które da się pokazać i porównać. To jest moment, kiedy widać, czy zespół potrafi redukować scope bez utraty celu.

Jeśli miałbym wskazać jedną rzecz, to rytm dostarczania. Jeśli po 2 sprintach nie ma działającego przyrostu i feedbacku użytkowników, to nie jest MVP-flow. Sprint bez demo i decyzji zamienia się w produkcję kodu, nie w walidację. W MVP liczy się ciąg: backlog, sprint, demo, decyzja, korekta hipotezy.

Dobre opisy procesu MVP pokazują nie tylko development, ale też sposób definiowania hipotez i priorytetów, co widać na przykład w materiałach o projektowaniu MVP w Software House Selleo. Wybierasz dostawcę MVP po tym, czy potrafi prowadzić uczenie się, a nie po tym, czy umie „dowieźć zakres”. To jest różnica między iteracją a waterfall w przebraniu. A ta różnica decyduje o budżecie, terminie i długu technicznym.

1. Ustal 1 cel MVP (jakiej hipotezy uczysz się).
2. Zdefiniuj minimalny flow (1–2 kluczowe scenariusze).
3. Zapisz kryterium „stop/continue” po sprincie (np. metryka, insight).
4. Dopiero wtedy porównuj oferty (czy dowożą uczenie się, nie slajdy).

12 pytań do Vendora, które odsiewają 90% pytań

• Jaki jest cel MVP jako hipoteza do sprawdzenia i jaką decyzję podejmiemy po 2 sprintach?
• Co dokładnie będzie wynikiem discovery: backlog, priorytety, Definition of Done, plan testów?
• Kto konkretnie będzie pracował przy projekcie (imiona/role), a nie tylko „zespół” z oferty?
• Czy dostaniemy dostęp do repozytorium od dnia 1 i jakie będą uprawnienia (read/write, owner)?
• Jak wygląda Wasz rytm dowożenia: demo co 1–2 tygodnie, co pokazujecie na demo i jak spisujecie decyzje?
• Jakie macie minimalne standardy jakości: code review, testy, CI/CD i jak to weryfikujecie w praktyce?
• Jak będziecie mierzyć postęp, jeśli zakres się zmienia (MVP): jakie metryki/artefakty raportujecie co sprint?
• Co uznajecie za „czerwone flagi” po stronie klienta i jak zareagujecie, jeśli zobaczycie ryzyko?
• Jak wygląda plan ograniczania kosztów w T&M: cap, milestone’y, zasady stop/continue?
• Co musi się wydarzyć, żeby fixed price miał sens i jakie są założenia/wyłączenia oferty?
• Jak wygląda exit plan: przekazanie kodu, dokumentacji, środowisk, haseł, kont i automatyzacji?
• Jak potwierdzicie wiarygodność: referencje do rozmowy, case z mierzalnymi wynikami, opinie z weryfikacją?

Jak porównać oferty software house do MVP, gdy każda jest inna? (macierz scoringowa + decyzje)

Porównywanie ofert działa dopiero wtedy, gdy oceniasz te same osie: kontrolę (repo/IP), proces (demo/DoD), jakość (review/testy) i ryzyko budżetu (model kontraktu). Jeśli oferta nie ma jawnych założeń i wyłączeń („nie obejmuje…”), to wycena nie jest porównywalna niezależnie od ceny. Jeśli oferta pomija UX, ryzykujesz MVP „działające technicznie, ale nieużywalne”, dlatego porównując dostawców sprawdzaj, jak opisują projektowanie i testy użyteczności tak jak poprawnie opisuje to np. Selleo web design company.

Najpierw ujednolićmy język porównania. Macierz scoringowa zamienia „wrażenia po callu” na kryteria, które da się sprawdzić. Wagi są proste: kontrola i jakość są ważniejsze niż lista funkcji w ofercie. W MVP wygrywa dostawca, który ogranicza ryzyko, nie ten, który obiecuje najwięcej.

Kontrola ma dwa twarde elementy: repo i IP. Brak dostępu do repo i artefaktów to praktyczny lock-in, bo nie da się przenieść pracy. Exit plan nie jest „na później”, bo później jest już za drogo.

Model rozliczeń jest kolejną osią. T&M wymaga kontroli i transparentności, a fixed price wymaga zamrożonego scope. W MVP scope zmienia się po feedbacku, więc porównuj też mechanizmy ograniczania kosztu. Cap budżetowy i milestone’y są konkretami, które da się wpisać do umowy i sprawdzić w praktyce.

W projektach, gdzie MVP ma od razu działać na mobile, porównanie ofert powinno uwzględniać także ryzyko publikacji i utrzymania aplikacji, co dobrze ilustrują opisy zakresu typu tworzenie aplikacji mobilnych z Software House Selleo. Jeśli masz krótki runway, decyzja jest o ryzyku i czasie startu, nie o „najładniejszej prezentacji”.

• Dostęp do repo (kto, kiedy, jakie uprawnienia)
• Definition of Done (co znaczy „skończone”)
• Plan exit (przekazanie kodu, dokumentacji, środowisk)
• Założenia/wyłączenia oferty (co nie wchodzi w cenę)

Jak sprawdzić jakość software house bez CTO? (pilot sprint + dowody jakości + bezpieczeństwo + reputacja)

Jeśli nie masz benchmarku jakości, nie oceniaj „kodu w próżni”, tylko praktyki, które zostawiają ślad w repo: PR-y, review i testy. Pilot sprint 1–2 tygodnie wystarcza, by zobaczyć komunikację, jakość artefaktów i zdolność do cięcia scope. Gdy dostawca deklaruje konkretną technologię, poproś o dowody praktyk jakości (PR-y, testy, review), bo sama etykieta typu Ruby on Rails development ze specjalistami Selleo nie mówi jeszcze, jak wygląda delivery.

Pilot sprint ma być testem, nie „mini-projektem”. Wynikiem pilota ma być działający przyrost, repo z historią zmian i jasne decyzje po demo. Po pilocie powinieneś umieć odpowiedzieć, czy zespół komunikuje ryzyka.
I czy potrafi odrzucać funkcje, które nie zwiększają validated learning.

Dowody jakości są konkretne. Code review jest krytyczne, bo ręczny przegląd wykrywa problemy, których automaty nie wyłapią. Poproś o przykładowy PR z opisem, testami i decyzją z review. To jest „code review checklist” w praktyce, a nie w slajdzie.

Bezpieczeństwo nie jest dodatkiem, gdy w MVP są dane wrażliwe. ISO/IEC 27001:2022 jest standardem ISMS i działa jako sygnał dojrzałości procesu bezpieczeństwa. Certyfikat nie jest gwarancją jakości produktu, więc traktuj go jako sygnał. Decyzję opieraj o to, czy praktyki bezpieczeństwa istnieją w codziennej pracy.

Reputacja też ma zasady weryfikacji. Metodologia platform z opiniami pomaga oddzielić recenzje od marketingu, jeśli czytasz je jak dowody, nie jak hasła. Patrz na spójność opisów pracy. I porównuj recenzje z tym, co zobaczyłeś w pilocie i repo.

FAQ

Co musi być w ofercie, żeby dało się ją porównać z inną?

Oferta musi mieć założenia i wyłączenia, bo bez nich zakres jest ukryty. Jeśli nie ma sekcji „nie obejmuje”, oferta nie jest porównywalna.

Jak wygląda sensowny pilot sprint i co ma być wynikiem?

Pilot ma trwać 1–2 tygodnie i zakończyć się działającym przyrostem oraz repo z historią zmian. To jest test komunikacji i jakości artefaktów.

Jakie zapisy w umowie minimalizują vendor lock-in?

Minimalizuje go dostęp do repo od dnia 1, przeniesienie IP i plan exit obejmujący dokumentację oraz środowiska. Lock-in to koszt utrudniający zmianę dostawcy.

Kiedy fixed price ma sens, a kiedy prawie zawsze boli?

Fixed price ma sens tylko przy zamrożonym, rozpisanym zakresie i niskim ryzyku zmian. MVP zmienia zakres po feedbacku, więc ten warunek nie jest spełniony.

Jak czytać opinie na Clutch, żeby nie dać się nabrać?

Czytaj je jak dowody: spójność opisów współpracy, komunikacji i zakresu, a nie jak hasła. Platforma opisuje własną metodologię zbierania danych o dostawcach.

Co robić, jeśli dostawca nie chce dać dostępu do repo?

Odrzuć ofertę, bo brak repo od początku zwiększa koszt zmiany dostawcy i tworzy lock-in. To jest prosty test kontroli nad pracą.