Koszt opracowania MVP to cena odpowiedzi na jedno pytanie, a nie cena produktu. Branżowe benchmarki plasują prostą aplikację lub aplikację MVP w przedziale $5000–40 000, a typowy czas wdrożenia wynosi 2–3 miesiące. Ten przedział utrzymuje się tylko wtedy, gdy zakres pozostaje ukierunkowany na pojedynczy przepływ, który należy zweryfikować. W momencie, gdy pierwszy budżet zaczyna pokrywać funkcje, które nie są częścią tego przepływu, kwota ta przestaje być kosztem MVP, a staje się zaliczką na pełny produkt.
Prawdziwe pytanie kryjące się za pytaniem “ile kosztuje MVP”
Kiedy założyciel firmy pyta, ile kosztuje MVP, kwota, którą otrzymuje, jest prawie zawsze funkcją sformułowanego briefu, a nie rynku. Dwa zespoły podające tę samą stawkę przedstawią Ci szacunki różniące się trzykrotnie, ponieważ jeden odczyta Twój brief jako “jeden przepływ, od początku do końca, działający”, a drugi jako “wszystko z tej listy, cieńsze”.”
Zanim porównasz oferty, odpowiedz sobie na to pytanie: Co musi udowodnić Twój MVP?
Nie “że ludzie tego chcą”. To przeczucie, a nie test. Coś, co można zweryfikować i co jest konkretne: że kierownik magazynu faktycznie zeskanuje paletę, zamiast zapisać ją na papierze. Że wytwórnia odsłucha przesłany utwór i podejmie na jego podstawie decyzję. Że recepcjonistka w klinice przeniesie rezerwację w interfejsie, zamiast oddzwonić do pacjenta. Jedno zdanie, jeden aktor, jedno obserwowalne zachowanie.
Wszystko, co zostanie zakupione w ramach pierwszego budżetu, powinno być powiązane z tym zdaniem. Wszystko, co nie jest z nim powiązane, jest mile widziane, niezależnie od tego, jak oczywiste wydaje się w prezentacji.
Dlatego właśnie niedoszacowanie minimalnego produktu z wykonalnością jest tanie, a przeszacowanie drogie. Zaniżenie zakresu prowadzi do powstania czegoś, czego nie da się przetestować – wersji demonstracyjnej, a nie produktu. Zawyżenie zakresu prowadzi do powstania czegoś, co działa, ale jego wdrożenie zajmuje tak dużo czasu, że pytanie o rynek pozostaje bez odpowiedzi przez kolejne pół roku, a pieniądze przepadają, zanim pojawią się pierwsze rzeczywiste opinie użytkowników.
Koszty opracowania MVP: co należy uwzględnić w pierwszym budżecie
Praktycznym sposobem na kontrolowanie kosztów rozwoju aplikacji MVP nie jest negocjowanie stawki. Chodzi o podzielenie każdej proponowanej funkcji na trzy kategorie, a następnie egzekwowanie ustalonych granic. To właśnie sprawia, że 2–3-miesięczny czas wdrożenia jest realistyczny, a nie optymistyczny: harmonogram jest krótki, ponieważ zakres jest wąski, a nie dlatego, że ktoś pracuje szybciej.
| Wiaderko | Co tu jest | Wpływ na pierwszy budżet |
|---|---|---|
| Przepływ rdzenia | Kroki, które musi wykonać prawdziwy użytkownik, aby wywołać testowane zachowanie, od początku do końca, bez żadnych udziwnień | Wszystko. To jest budżet. |
| Wspieranie minimum | Autoryzacja, podstawowe role, stany błędów, wdrażanie, sposób sprawdzenia, co się stało | Małe, ale nie podlegające negocjacjom — bez niego nie można zaobserwować głównego przepływu w produkcji |
| Druga runda | Panele analityczne, rozbudowane profile, powiadomienia, panele administracyjne, funkcje społecznościowe, integracje, które nie są częścią dowodu | Zero. Zapisane, oszacowane później, nie zbudowane teraz. |
Dwie zasady gwarantują uczciwość.
Po pierwsze, rdzeń przepływu musi być realistyczny. Cięcie zakresu usuwa funkcje, a nie poprawność. Jeśli przepływ obejmuje przesłanie, przesłanie musi przetrwać duży plik przy słabym połączeniu, ponieważ to właśnie tam walidacja zakończy się niepowodzeniem. Zespoły, które skracają niewłaściwy wymiar — udostępniając każdą funkcję na liście działającą w połowie zamiast takiej, która działa za każdym razem — w końcu nie są w stanie stwierdzić, czy użytkownicy odrzucili pomysł, czy odrzucili błędy. Używaliśmy tego samego argumentu funkcja po funkcji, gdy spisywałem Porównanie MVP i V2 dla produktu fintech:pętla wartości, która nie działa niezawodnie, staje się droższa, a nie tańsza, gdy się do niej dodaje nowe funkcje.
Po drugie, “w końcu będziemy tego potrzebować” nie jest argumentem za budowaniem tego teraz. Analityka to typowy winowajca. Założyciele proszą o pulpity nawigacyjne w pierwszej rundzie, ponieważ pomiary brzmią jak walidacja. W przypadku grupy pilotażowej można policzyć na palcach jednej ręki, że zapytanie do bazy danych i arkusz kalkulacyjny dadzą ten sam wynik w jedno popołudnie. Pulpity nawigacyjne stają się warte swojej ceny, gdy ilość danych przekracza cierpliwość użytkownika, a to prawie nigdy nie zdarza się w pierwszej wersji.
Koszt stworzenia MVP zależy również od czynników, które nigdy nie pojawiają się na liście funkcji: ile systemów zewnętrznych musisz zaakceptować, ile ról użytkowników wymaga różnych uprawnień, ile części modelu danych tworzysz, a ile dziedziczysz. To te same mnożniki, które wpływają na każdą wycenę — szczegółowo je omówiliśmy w co tak naprawdę podnosi koszty oprogramowania niestandardowego, i żadna z nich nie jest widoczna w stawce godzinowej.
Przykład z naszej praktyki
DropYourDemo to platforma SaaS, którą stworzyliśmy dla Hexagon w Holandii w oparciu o Symfony i AWS. Muzycy przesyłają utwory, a wytwórnie słuchają ich, oceniają i filtrują za pomocą ustrukturyzowanego procesu zatwierdzania. Don Diablo jest jednym z jej użytkowników.
Pierwszy budżet miał dokładnie jedno zadanie: udowodnić, że wytwórnia faktycznie przeprowadzi demo przez cały proces aż do podjęcia decyzji. Nie chodzi o to, że artyści będą publikować – artyści będą publikować gdziekolwiek. Niesprawdzona połowa znajdowała się po drugiej stronie rynku. Zespoły A&R wytwórni miały już skrzynki odbiorcze pełne dem i nawyk ich ignorowania. Jeśli ustrukturyzowany proces recenzji nie zmienił tego nawyku, nic innego w produkcie nie miało znaczenia.
Zatem główny schemat działania wyglądał następująco: artysta przesyła utwór, trafia on do kolejki wytwórni w zdefiniowanym stanie, ktoś po stronie wytwórni słucha go, ocenia, a zgłoszenie jest przesyłane dalej lub zostaje odfiltrowane. Przesłanie, kolejka, przegląd, decyzja. Symfony obsługiwał aplikację i przejścia między stanami, AWS zajmował się przechowywaniem i dostarczaniem dużych plików audio, które muszą być odtwarzane natychmiast, w przeciwnym razie recenzent się podda. Ten ostatni szczegół nie był niczym miłym – przebieg przeglądu, w którym odtwarzanie się zacina, to przebieg przeglądu, którego nikt nie kończy, a walidacja mierzyłaby naszą infrastrukturę, a nie ich zachowanie.
Czego celowo pominęliśmy w pierwszej rundzie: analizy trendów zgłoszeń, bogaty profil artysty z biografią i linkami społecznościowymi oraz funkcje społecznościowe, które ostatecznie sprawiłyby, że platforma stałaby się społecznością. Wszystkie te elementy znajdowały się na pierwotnej liście życzeń. Każdy z nich byłby możliwy do obrony w oderwaniu od reszty. Żaden z nich nie zmienił odpowiedzi na pytanie, na które liczył budżet.
Gdy wytwórnie wyraźnie przesuwały dema przez proces zatwierdzania, druga runda miała coś, na czym można było się oprzeć – i, co bardziej przydatne, rzeczywiste opinie użytkowników na temat tego, z którymi częściami kolejki mieli problemy. Te opinie uporządkowały zaległości w sposób, którego nie dałoby się osiągnąć na żadnej sesji planowania. Możesz przeczytać pełną wersję Studium przypadku DropYourDemo dla szerszego obrazu.
Na co zwrócić uwagę
Presja inwestorów na stworzenie kompletnego produktu. Najczęstszym sposobem na zmarnowanie pierwszego budżetu jest przekonanie założyciela, że wąski produkt nikogo nie zachwyci. Warto powiedzieć wprost: działający, pojedynczy przepływ z prawdziwymi użytkownikami jest lepszy niż szeroka wersja demo bez żadnych użytkowników, zarówno podczas rozmowy o finansowaniu, jak i wszędzie indziej. Jeśli inwestorzy się nie zgadzają, to jest to rozmowa, którą należy przeprowadzić przed, a nie po określeniu zakresu.
Rozszerzanie zakresu działania pod przykrywką polerowania. “Skoro już tam jesteśmy” – tak budowa na jedną ćwiartkę po cichu zamienia się w dwie. Każdy dodatek jest niewielki; całość to inny projekt. Prowadź pisemną listę odłożonych rzeczy, aby odpowiedź brzmiała “tak, jest na liście do drugiej rundy” zamiast “nie”.”
Potraktowanie minimalnego kosztu produktu gotowego do sprzedaży jako rabatu za jakość. Ograniczanie zakresu jest uzasadnione. Ograniczanie testów, obsługi błędów czy higieny wdrożenia to zadłużanie się w tempie, którego jeszcze nie widać. W drugiej rundzie dowiadujesz się, ile to kosztuje, zazwyczaj w postaci przepisania.
Niedocenianie tego, co dzieje się po starcie. Budżet MVP to nie ostatnia partia. Po zatwierdzeniu głównego przepływu, kolejna runda jest zazwyczaj większa, ponieważ teraz budujesz budżet na retencję, a nie na dowód. Zaplanuj pierwszy budżet, wiedząc, że istnieje drugi; nie wydawaj go zbyt wcześnie.
Niepodjęcie decyzji z góry, co ma wyglądać jako “udowodnione”. Zdefiniuj próg przed rozpoczęciem tworzenia. Ile decyzji w leju, od ilu różnych użytkowników i w jakim okresie, uznaje się za „tak”? Bez tego progu każdy wynik staje się dyskusyjny, a walidacja, za którą zapłaciłeś, zmienia się w kolejną opinię.
Wniosek
Koszt opracowania MVP najlepiej interpretować jako cenę konkretnego dowodu, a branżowy zakres od $5000 do 40 000 w ciągu 2–3 miesięcy opisuje projekty, w których utrzymano ten poziom. Dźwignią, która zmienia tę kwotę, jest zakres, a nie stawka — które funkcje uczestniczą w testowanym głównym przepływie, a które czekają na drugą rundę. W przypadku DropYourDemo oznaczało to przesłanie, kolejkę, przepływ przeglądu i decyzję, a analizy i profile były wstrzymywane do momentu, aż etykiety udowodnią, że lejek zadziałał. Jeśli ustalasz pierwszy budżet i nie masz pewności, gdzie leży granica, nasze zespół ds. rozwoju produktu Czy tego typu prace nad zakresem działalności są regularnie prowadzone z założycielami?.
Powiedz nam, co Twój produkt musi udowodnić, a my powiemy Ci, jak to udowodnić.
