Jak zbudować MVP, które czegoś dowodzi

MVP ma sens tylko wtedy, gdy potrafisz jednym zdaniem powiedzieć, czego dowodzi. „Czy ktoś zapłaci za automatyczne rozliczanie kierowców?” to pytanie. „Panel, rejestracja, płatności i raporty” to lista funkcji - z niej nie wynika żaden wniosek.

Zapisz pytanie i warunek jego rozstrzygnięcia, zanim powstanie pierwsza linia kodu. Na przykład: dziesięciu klientów kończy proces bez pomocy telefonicznej, albo trzech płaci z góry. Bez tego warunku każdy wynik da się wytłumaczyć na swoją korzyść, a MVP zamienia się w bezterminowy projekt.

Ta jedna decyzja rozstrzyga potem wszystko inne: co trzeba zbudować, co można zrobić ręcznie i czego nie robić wcale.

Typowa lista wymagań pierwszej wersji zawiera panel administracyjny, role użytkowników, powiadomienia mailowe, eksport do CSV i integrację z systemem księgowym. Żadna z tych rzeczy nie odpowiada na pytanie z poprzedniego akapitu - wszystkie są potrzebne dopiero wtedy, gdy odpowiedź brzmi „tak”.

Efekt jest zawsze ten sam: budżet kończy się przed pierwszym prawdziwym użytkownikiem, a wnioski trzeba wyciągać z tego, co zdążyło powstać. Najdroższa wersja MVP to ta, która nie zdążyła nikomu niczego pokazać.

Drugi błąd tej samej rodziny to budowanie pod skalę, której jeszcze nie ma. Architektura pod milion użytkowników, gdy nie ma ani jednego, kosztuje realne tygodnie i nie kupuje nic poza spokojem sumienia.

Praktyczna metoda: przejdź listę funkcji i każdej przypisz jedną z trzech kategorii.

• Konieczne do rozstrzygnięcia pytania - buduję. Zwykle są to dwie, trzy funkcje, nie dwadzieścia.
• Potrzebne, ale da się zrobić ręcznie - robi człowiek. Weryfikacja konta mailem, wystawienie faktury, wgranie danych klienta. Dopóki użytkowników jest dziesięciu, ręczna obsługa jest tańsza od automatyzacji i uczy więcej o procesie.
• Potrzebne później - na listę, z datą przeglądu. Nie kasujemy, ale też nie budujemy „przy okazji”, bo przy okazji nie istnieje.

Na tym etapie technologia ma być nudna i znajoma zespołowi, który ją utrzyma. Egzotyczny wybór, który wygląda dobrze w prezentacji, zwykle kosztuje dwa tygodnie na rozwiązywanie problemów, których nikt jeszcze nie opisał w internecie.

Praktycznie: jedna baza, jeden serwis aplikacyjny, jeden mechanizm kolejkowy tylko jeśli jest naprawdę potrzebny. Mikroserwisy na etapie MVP to prawie zawsze błąd - dokładają koszt operacyjny, zanim istnieje problem, który miałyby rozwiązać.

Hosting dobieram do etapu, nie do ambicji. Vercel albo prosty PaaS dają najkrótszy czas do pierwszego wdrożenia; Azure lub AWS mają sens, gdy istnieją wymagania dotyczące danych albo integracji korporacyjnych. Ważniejsze od wyboru dostawcy jest to, żeby wdrożenie było automatyczne od pierwszego tygodnia - ręczne wdrażanie zabija tempo szybciej niż jakikolwiek wybór technologiczny.

CI/CD, monitoring błędów i kopie zapasowe wchodzą od początku. To łącznie dzień pracy, a bez nich pierwsza awaria kosztuje więcej.

Sensowne MVP to od czterech do dwunastu tygodni pracy. Poniżej czterech tygodni zwykle nie ma czego wdrażać; powyżej trzech miesięcy to już nie jest MVP, tylko produkt budowany bez informacji zwrotnej z rynku.

Koszt jest pochodną zakresu i tego, ile decyzji jest już podjętych po Twojej stronie. Największym pojedynczym czynnikiem kosztotwórczym nie jest technologia, tylko zmienność wymagań: projekt, w którym zakres zmienia się co tydzień, kosztuje dwa razy więcej niż ten sam projekt z zamrożonym zakresem pierwszej wersji.

Realny punkt odniesienia dla polskiego rynku: budowa MVP prowadzonego przez jedną doświadczoną osobę mieści się zwykle w przedziale kilkudziesięciu tysięcy złotych. Jeśli oferta jest wyraźnie niższa, sprawdź, kto będzie utrzymywał efekt i czy kod będzie Twój.

Po wypuszczeniu MVP są tylko trzy możliwe decyzje: rozwijamy, zmieniamy kierunek albo zamykamy. Wszystkie trzy są dobrym wynikiem, bo każda oszczędza pieniądze - najgorszy scenariusz to brak rozstrzygnięcia i cicha kontynuacja „bo już tyle w to włożyliśmy”.

Jeśli decyzja brzmi „rozwijamy”, to jest właściwy moment na rzeczy, które świadomie odłożyliśmy: role, panel administracyjny, automatyzację procesów robionych dotąd ręcznie i architekturę pod realny, a nie wyobrażony ruch. Teraz wiadomo już, które z nich są potrzebne.

Niezależnie od decyzji: kod, repozytorium, infrastruktura i dokumentacja mają być Twoje od pierwszego dnia. Bez tego nie masz wyjścia awaryjnego, a każda kolejna rozmowa o cenie odbywa się z pozycji słabszej.