MVP, czyli minimalną wersję produktu, buduje się od pytania, na które ma odpowiedzieć, a nie od listy funkcji. Jedna grupa użytkowników, jedna ścieżka od wejścia do wyniku i jedna liczba, która po ustalonym czasie powie, czy iść dalej. Wszystko, co nie jest potrzebne, żeby tę liczbę zmierzyć, trafia na listę "nie teraz".
Budżet na pierwszą wersję przepala się zwykle na dwa sposoby. Pierwszy to budowanie zbyt wielu funkcji, zanim produkt zobaczy pierwszy prawdziwy użytkownik. Drugi jest mniej oczywisty: oszczędności w miejscach, których nie da się tanio poprawić później, takich jak model danych, uprawnienia czy obsługa płatności.
- MVP to narzędzie do zdobycia wiedzy o użytkownikach, a nie okrojona wersja docelowego produktu. Zaczyna się od hipotezy, która może się nie potwierdzić.
- Zakres wyznacza jedna grupa użytkowników i jedna ścieżka. Każda funkcja, bez której ta ścieżka się nie urywa, idzie na listę "nie teraz" z zapisanym powodem.
- Oszczędzaj na wyglądzie, panelu administracyjnym, automatyzacji i skali. Nie oszczędzaj na modelu danych, uprawnieniach, płatnościach, kopiach zapasowych i formalnościach.
- Liczbę, próg i datę oceny ustal przed startem, a część budżetu zostaw na zmiany po starcie.
- Przepisanie całości rzadko jest dobrą decyzją. Częściej opłaca się wymieniać kod modułami.
Czym jest MVP, a czym nie jest
Eric Ries, który spopularyzował to pojęcie, zdefiniował w 2009 roku minimalną wersję produktu jako taką, która pozwala zespołowi zebrać najwięcej zweryfikowanej wiedzy o klientach przy najmniejszym wysiłku. Najważniejsze w tej definicji jest słowo "wiedza". Minimalny ma być wysiłek, a nie produkt. MVP, które działa, ale niczego nie rozstrzyga, było po prostu tańszym projektem, a nie eksperymentem.
W praktyce pod nazwą MVP kryją się rzeczy, które odpowiadają na zupełnie różne pytania. Zanim zamówisz wycenę, sprawdź, czego właściwie potrzebujesz:
MVP a prototyp i proof of concept
| Forma | Na jakie pytanie odpowiada | Kto z niej korzysta |
|---|---|---|
| Makieta albo klikalny prototyp | Czy ludzie rozumieją, jak produkt działa i co w nim zrobić | Kilka osób na rozmowach, bez prawdziwych danych |
| Proof of concept | Czy da się to technicznie zbudować, na przykład czy dane z jednego systemu da się przetworzyć w potrzebnym czasie | Zespół, nikt z zewnątrz |
| MVP | Czy ludzie użyją produktu w prawdziwej sprawie i czy za to zapłacą | Pierwsza, wąska grupa prawdziwych użytkowników |
| Pierwsza wersja komercyjna | Czy produkt sprawdza się na szerszym rynku i jak go sprzedawać | Wszyscy klienci z grupy docelowej |
Pomylenie tych form kosztuje w obie strony. Klikalny prototyp nazwany MVP daje opinie, ale nie daje danych o zachowaniu, bo nikt w nim niczego naprawdę nie załatwia. Pełna wersja komercyjna nazwana MVP pochłania budżet przeznaczony na naukę i nie zostawia pieniędzy na zmianę kierunku.
MVP nie zawsze wymaga kodu. Część hipotez da się sprawdzić stroną z formularzem zapisu albo usługą wykonywaną ręcznie, za którą klient płaci, zanim powstanie automatyzacja. Kod jest potrzebny wtedy, gdy wartością produktu jest sama automatyzacja, gdy test wymaga prawdziwych płatności wielu użytkowników naraz albo gdy klient biznesowy musi podłączyć produkt do swoich procesów, żeby go ocenić.
Zanim zbudujesz MVP, zapisz hipotezę, która może się nie potwierdzić
Hipoteza to jedno zdanie, które da się sprawdzić i które może okazać się fałszywe. Wygodny szablon wygląda tak: "Wierzymy, że [kto] zrobi [co], bo [jaki problem]. Uznamy to za potwierdzone, jeśli do [data] co najmniej [liczba] [kogo] zrobi [konkretną rzecz]".
W całym tekście posłużymy się jednym przykładem, wymyślonym na potrzeby poradnika. Załóżmy produkt dla małych szkół językowych, które dziś przyjmują zapisy przez telefon i rozliczają się przelewami. Hipoteza mogłaby brzmieć: "Wierzymy, że właściciele małych szkół językowych przeniosą zapisy na kursy do systemu z płatnością online, bo ręczne pilnowanie wpłat zajmuje im czas i generuje pomyłki. Uznamy to za potwierdzone, jeśli w ciągu ośmiu tygodni od startu co najmniej pięć szkół przyjmie przez system zapisy na płatny kurs".
Liczby w tym przykładzie są umowne. Ważne, że zdanie zawiera konkretną grupę, zachowanie, próg i datę. Zdanie "sprawdzimy, czy szkoły są zainteresowane" nie jest hipotezą, bo nie da się go obalić. Zainteresowanie zawsze jakieś jest.
Każdy produkt opiera się na kilku założeniach naraz: że problem istnieje, że rozwiązanie go usuwa, że ludzie za to zapłacą, że da się do nich dotrzeć i że produkt da się zbudować w rozsądnym koszcie. MVP powinno sprawdzić założenie najbardziej ryzykowne i najmniej pewne. Jeśli największą niewiadomą jest to, czy szkoły zechcą płatności online, nie ma sensu budować najpierw zaawansowanego grafiku zajęć.
Zanim zlecisz budowę, porozmawiaj z kilkoma osobami z grupy docelowej i zapytaj, jak dziś rozwiązują problem i ile ich to kosztuje. Nie pytaj, czy skorzystałyby z Twojego produktu, bo prawie każdy z grzeczności odpowie, że tak. Pytaj o to, co już robią, bo zachowanie z przeszłości mówi więcej niż deklaracja na przyszłość.
Jak zbudować MVP: jedna grupa, jedna ścieżka, jeden wynik
Zakres pierwszej wersji wynika wprost z hipotezy. Jeśli hipoteza jest dobrze zapisana, większość decyzji o funkcjach podejmuje się sama, bo przy każdej wystarczy zapytać, czy bez niej da się sprawdzić hipotezę.
W przykładzie są to małe szkoły językowe z jednym oddziałem, a nie wszystkie placówki edukacyjne. Węższa grupa oznacza mniej wyjątków do obsłużenia i czytelniejszy wynik.
Szkoła zakłada konto, dodaje kurs z terminem i ceną, wysyła link. Kursant otwiera link, zapisuje się i płaci. Szkoła widzi listę zapisanych i wpłaty.
Przy każdym zapytaj, czy bez niego ścieżka się urywa. Jeśli nie, krok idzie na listę "nie teraz".
Wszystko, co przez pierwsze tygodnie może robić człowiek, na przykład zakładanie kont szkołom albo wysyłka podsumowań, robi człowiek.
Przy każdej odłożonej funkcji zapisz, dlaczego jej nie ma i jaki sygnał od użytkowników sprawi, że wróci.
Data jest stała, a zmienia się zakres. Jeśli coś nie zdąży, wypada z pierwszej wersji, zamiast przesuwać start.
Krok szósty jest najtrudniejszy, bo w trakcie budowy zawsze pojawia się funkcja, która wydaje się niezbędna. Każdy tydzień opóźnienia startu to tydzień, w którym płacisz za rozwój produktu, nie wiedząc, czy idzie we właściwym kierunku.
Co powinno zawierać MVP, a co odkładasz na później
Lista "nie teraz" jest równie ważna jak lista funkcji. Pokazuje wykonawcy, gdzie są granice zakresu, a Tobie przypomina w trakcie projektu, że odłożenie czegoś było decyzją, a nie przeoczeniem. Dla przykładowego produktu mogłaby wyglądać tak:
Przykładowy zakres MVP
| Funkcja | W pierwszej wersji | Dlaczego |
|---|---|---|
| Konto szkoły i dodawanie kursu | Tak | Bez tego ścieżka nie istnieje |
| Zapis kursanta i płatność online | Tak | To jest zachowanie, które testuje hipoteza |
| Lista zapisanych z eksportem do CSV | Tak | Szkoła musi z tymi danymi pracować od pierwszego dnia |
| Powiadomienie e-mail o zapisie | Tak | Bez niego szkoła nie wie, że coś się wydarzyło |
| Faktury | Wystawiane w programie, którego szkoła już używa | Fakturowanie nie jest testowaną hipotezą |
| Aplikacja mobilna | Nie, strona działająca na telefonie | Do sprawdzenia hipotezy wystarczy przeglądarka |
| Powiadomienia SMS | Nie | E-mail wystarcza do testu, SMS to koszt za każdą wiadomość |
| Raporty i wykresy | Nie, eksport do arkusza | Przy kilku szkołach raport można przygotować ręcznie |
| Wiele oddziałów i konta lektorów | Nie, ale model danych jest na to gotowy | Rozszerzenie jest prawdopodobne, więc nie może wymagać przebudowy |
| Kody rabatowe i polecenia | Nie | Bez ruchu nie da się ocenić, czy działają |
| Wersja angielska | Nie | Grupa docelowa pierwszej wersji jest polskojęzyczna |
Zwróć uwagę na wiersz o oddziałach. Funkcji nie ma, ale model danych od pierwszego dnia zakłada, że kursy należą do szkoły, a szkoła może mieć więcej niż jedno miejsce prowadzenia zajęć. Na etapie projektowania bazy kosztuje to niewiele, a pozwala uniknąć migracji danych prawdziwych klientów kilka miesięcy później.
Najczęstszy argument za dodaniem funkcji do MVP brzmi "to przecież tylko jeden dzień pracy". Nawet jeśli to prawda, funkcję trzeba potem testować, utrzymywać i uwzględniać przy każdej zmianie. Do tego rozmywa pomiar: jeśli szkoły zaczną korzystać z produktu, nie wiadomo, czy przyciągnęła je płatność online, czy kody rabatowe.
Ta sama logika dotyczy wyboru między aplikacją mobilną a stroną. Jeśli hipoteza nie dotyczy funkcji dostępnych wyłącznie w aplikacji ze sklepu, MVP w przeglądarce sprawdzi ją taniej i szybciej. Kiedy aplikacja ze sklepu jest naprawdę potrzebna, opisaliśmy w tekście aplikacja mobilna czy PWA.
Na czym oszczędzać w MVP, a czego nie upraszczać
Zasada jest prosta: oszczędzaj tam, gdzie późniejsza zmiana jest tania, a nie upraszczaj tam, gdzie późniejsza zmiana dotyka danych prawdziwych użytkowników albo ich pieniędzy. Wygląd przycisku zmienia się w godzinę. Model danych, w którym nie wiadomo, do kogo należy rekord, zmienia się tygodniami, bo trzeba przenieść dane, poprawić uprawnienia i sprawdzić każdą funkcję, która z nich korzysta.
Gdzie ciąć, a gdzie nie
| Obszar | Można uprościć | Nie upraszczaj |
|---|---|---|
| Wygląd | Spójny zestaw prostych komponentów zamiast dopracowanych ilustracji i animacji | Czytelność, działanie na telefonie, poprawne formularze i komunikaty błędów |
| Panel administracyjny | Minimalny, część operacji wykonuje ręcznie zespół | Uprawnienia, czyli kto widzi czyje dane |
| Model danych | Mniej pól i mniej rodzajów rekordów | Relacje i przynależność danych, na przykład szkoła jako właściciel kursów od pierwszego dnia |
| Płatności | Jeden operator i strona płatności operatora | Potwierdzanie płatności po stronie serwera na podstawie powiadomienia od operatora |
| Infrastruktura | Jeden serwer, bez automatycznego skalowania | Kopie zapasowe ze sprawdzonym odtwarzaniem, HTTPS, aktualizacje bezpieczeństwa |
| Integracje | Eksport i import plików CSV | Unikalne identyfikatory, które pozwolą później podłączyć inne systemy |
| Testy | Ręczne przeklikanie głównej ścieżki przed każdym wdrożeniem | Testy automatyczne dla płatności i uprawnień |
| Formalności | Krótkie, jasne dokumenty zamiast rozbudowanych | Regulamin, informacja o przetwarzaniu danych i zgody tam, gdzie są wymagane |
Płatności zasługują na osobne zdanie. Przekierowanie przeglądarki z powrotem do sklepu po zapłacie nie jest potwierdzeniem płatności, bo klient może zamknąć kartę przeglądarki albo stracić połączenie, a adres powrotu da się otworzyć ręcznie. Status "opłacone" powinien ustawiać serwer po otrzymaniu powiadomienia od operatora płatności. To niewielka dodatkowa praca, a bez niej zdarzają się zamówienia oznaczone jako opłacone bez pieniędzy albo opłacone, których nikt nie realizuje.
Formalności też nie są dodatkiem na później. Jeśli w ramach produktu świadczysz usługi drogą elektroniczną, musisz określić regulamin i udostępnić go przed zawarciem umowy (art. 8 ustawy o świadczeniu usług drogą elektroniczną). Jeśli zbierasz dane osobowe, a MVP prawie zawsze to robi, musisz poinformować o ich przetwarzaniu zgodnie z RODO. Narzędzia analityczne i reklamowe, które zapisują informacje na urządzeniu użytkownika albo je z niego odczytują, co do zasady wymagają jego uprzedniej zgody (art. 399 Prawa komunikacji elektronicznej). Wyjątkiem są między innymi zapisy niezbędne do świadczenia usługi, o którą użytkownik prosi.
Jeśli produkt sprzedaje konsumentom przez stronę albo aplikację, sprawdź też ustawę o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, stosowaną od 28 czerwca 2025 roku. Jak przypomina rządowy serwis o dostępności cyfrowej, nie dotyczy ona usług oferowanych przez mikroprzedsiębiorców, ale wyłączenie znika, gdy firma przestanie być mikroprzedsiębiorcą. Podstawowa dostępność, czyli opisane pola formularzy, obsługa klawiaturą i wystarczający kontrast, kosztuje na starcie niewiele, a dorabiana później dużo więcej.
Gotowe usługi zamiast własnego kodu
Nie wszystko w MVP trzeba pisać. Płatności obsługuje operator, maile transakcyjne zewnętrzna usługa wysyłkowa, logowanie może opierać się na sprawdzonej bibliotece, a część procesów da się na start poprowadzić w narzędziu no-code. Reguła, która dobrze się sprawdza: kupuj to, co nie jest Twoją przewagą, a buduj to, co testujesz.
Każda gotowa usługa ma jednak trzy koszty, które warto znać przed wyborem:
- Cena rośnie z użyciem. Opłata za użytkownika albo za transakcję przy kilku klientach jest pomijalna, przy kilku tysiącach może stać się największą pozycją w budżecie.
- Limity planu. Liczba rekordów, automatyzacji albo zapytań do API potrafi zatrzymać produkt wtedy, gdy zaczyna rosnąć.
- Eksport danych. Logika zbudowana w narzędziu no-code zwykle nie daje się wyeksportować, więc przy przenosinach trzeba ją odtworzyć w kodzie.
Ten sam rachunek opisaliśmy szerzej w tekście panel zamiast arkusza. Dla MVP wniosek jest podobny: no-code to dobry wybór, jeśli hipoteza dotyczy popytu, a nie samej automatyzacji, i jeśli z góry zakładasz, że po jej potwierdzeniu produkt powstanie od nowa w kodzie.
Budżet MVP: zbudowanie to dopiero pierwsza część
Najczęstszy sposób na przepalenie budżetu to wydanie go w całości na pierwszą wersję. Produkt startuje, pierwsi użytkownicy pokazują, co trzeba zmienić, a pieniędzy na te zmiany już nie ma. Tymczasem właśnie te zmiany są powodem, dla którego MVP się buduje.
Planuj budżet w dwóch częściach: zbudowanie wersji, która sprawdzi hipotezę, i kilka rund poprawek po starcie, opartych na tym, co użytkownicy robią. Jeśli całość się nie mieści, tnij zakres pierwszej części, a nie drugą część.
Ten podział dobrze pasuje do różnych modeli rozliczenia. Pierwsza wersja z jasno opisanym zakresem i listą "nie teraz" nadaje się do wyceny ryczałtowej, a rozwój po starcie, którego zakresu z definicji nie znasz, łatwiej rozliczać godzinowo z ustalonym limitem. Różnice między tymi modelami i ryzyko po każdej stronie opisaliśmy w tekście fixed price czy time and material.
Do kosztu zbudowania doliczają się koszty cykliczne, o których łatwo zapomnieć przy pierwszej wycenie: serwer, domena, prowizje operatora płatności, usługa wysyłki maili, płatne API i aktualizacje bezpieczeństwa. Przy porównywaniu ofert sprawdzaj, czy wycena obejmuje ten sam zakres i co jest z niej wyłączone. Jak to zrobić krok po kroku, pokazujemy w tekście jak czytać wycenę software house'u.
Kontrola budżetu w trakcie budowy sprowadza się do kilku nawyków:
- Działająca wersja co tydzień. Oglądasz postęp na środowisku testowym, przeklikując ścieżkę, a nie na slajdach.
- Każdy nowy pomysł trafia na listę "nie teraz". Wraca do zakresu tylko wtedy, gdy coś innego z niego wypada.
- Jedna osoba po Twojej stronie podejmuje decyzje. Pytania wykonawcy czekające dniami na odpowiedź wydłużają projekt bardziej niż większość problemów technicznych.
Każda funkcja dodana przed startem przesuwa moment, w którym dowiesz się, czy produkt ma sens. Jeśli lista funkcji rośnie, a data startu się oddala, projekt przestał być eksperymentem i stał się budową na kredyt niesprawdzonych założeń.
Jak mierzyć MVP: liczba, próg i data przed startem
Zanim produkt wystartuje, zapisz trzy rzeczy: którą liczbę obserwujesz, jaki próg uznasz za sukces i kiedy ją ocenisz. Do tego dopisz, co zrobisz przy każdym wyniku. Bez tych zapisów każdy wynik da się zinterpretować jako zachęcający, bo zawsze znajdzie się jakaś rosnąca linia na wykresie.
Część liczb dobrze wygląda w prezentacji, ale nie odpowiada na pytanie z hipotezy.
Metryki MVP
| Metryka | Co mówi | Pułapka |
|---|---|---|
| Rejestracje | Czy opis produktu przyciąga właściwe osoby | Nie mówi nic o tym, czy produkt działa |
| Aktywacja, czyli pierwsze przejście głównej ścieżki | Czy ludzie dochodzą do wartości | Definicja musi być ścisła, na przykład "szkoła przyjęła pierwszą płatność", a nie "zalogowała się" |
| Powroty w kolejnych tygodniach | Czy produkt jest potrzebny regularnie, a nie raz | Przy małej liczbie użytkowników pojedyncza osoba mocno zmienia wynik |
| Płatność albo wiążące zobowiązanie | Czy wartość jest warta pieniędzy | Darmowy pilotaż nie odpowiada na to pytanie |
| Czas do pierwszego wyniku | Ile tarcia jest na ścieżce | Średnia ukrywa osoby, które utknęły i zrezygnowały |
| Rezygnacje i ich powody | Co nie działa | Bez rozmowy znasz tylko liczbę, a nie przyczynę |
Przy MVP liczby są małe i to trzeba uczciwie uwzględnić. Jeśli produkt ma piętnastu aktywnych użytkowników, jedna osoba to prawie siedem punktów procentowych. Wykres retencji z takiej grupy więcej mówi o konkretnych ludziach niż o trendzie. Dlatego przy pierwszej wersji pomiar ilościowy zawsze uzupełnia się rozmowami. Z każdym użytkownikiem, który zrezygnował, i z każdym, który używa produktu częściej niż inni, warto porozmawiać osobiście.
Najpewniejsze dane do oceny MVP pochodzą z bazy samego produktu. Zdarzenia takie jak założenie konta, opublikowanie kursu czy potwierdzona płatność zapisuje serwer, więc nie zależą od blokad reklam ani od zgody na cookies. Analityka w przeglądarce wymaga zgody, o której mowa wyżej, i części użytkowników nie zobaczy. Przyda się do szukania miejsc, w których ludzie porzucają ścieżkę, ale do oceny hipotezy zwykle wystarczy kilka zapytań do bazy raz w tygodniu.
Po starcie: rozwijać, zmienić kierunek czy zamknąć
Po ustalonym czasie porównujesz wynik z progiem. Rzadko wychodzi czyste "tak" albo "nie", ale wzorce wyników powtarzają się na tyle, że da się je z góry przypisać do decyzji:
Wynik MVP i następny krok
| Wynik | Co zwykle oznacza | Następny krok |
|---|---|---|
| Próg przekroczony, użytkownicy wracają | Hipoteza się potwierdziła | Przegląd listy "nie teraz", uporządkowanie kodu, plan kolejnej wersji |
| Dużo rejestracji, mało aktywacji | Obietnica przyciąga, ale ścieżka zawodzi albo produkt robi co innego, niż obiecuje opis | Rozmowy z osobami, które odpadły, poprawa ścieżki, a nie nowe funkcje |
| Aktywacja jest, powrotów nie ma | Potrzeba jest jednorazowa albo wartość za mała | Sprawdzenie, czy inna grupa ma tę potrzebę częściej |
| Używają, ale nie płacą | Wartość nie uzasadnia ceny albo płacić powinien ktoś inny | Test innej ceny albo innego płacącego, na przykład firmy zamiast osoby |
| Mało kto w ogóle trafia do produktu | Problem z dotarciem, a nie z produktem | Zmiana kanału pozyskania, zanim zmieni się produkt |
Zamknięcie projektu po MVP nie oznacza zmarnowanego budżetu. MVP, które pokazało, że główne założenie było błędne, wykonało swoje zadanie za ułamek ceny pełnego produktu. Zmarnowany jest budżet, po którym nadal nie wiadomo, czy założenie było prawdziwe, bo nikt nie zapisał progu ani daty.
Przy wyniku pośrednim częstym błędem jest dobudowywanie funkcji w nadziei, że któraś przechyli szalę. Jeśli ludzie nie przechodzą głównej ścieżki, kolejna funkcja obok niej niczego nie zmieni.
Kiedy przepisać MVP, a kiedy rozwijać istniejący kod
Pierwsza wersja ma prawo być napisana szybciej i mniej starannie niż docelowy produkt. Ward Cunningham opisał to w 1992 roku metaforą długu, od której wzięło się pojęcie długu technicznego: kod napisany po raz pierwszy jest jak dług, który przyspiesza pracę, o ile zostanie szybko spłacony. Gdy nikt go nie spłaca, każda kolejna zmiana płaci odsetki w postaci dłuższej pracy i nowych błędów.
Naturalną reakcją na rosnący dług jest pomysł, żeby wszystko przepisać od nowa. Joel Spolsky w 2000 roku nazwał przepisywanie oprogramowania od zera najgorszym strategicznym błędem, jaki może popełnić firma programistyczna, na przykładzie Netscape, w którym od wydania wersji 4.0 do publicznej bety wersji 6.0 minęły prawie trzy lata. Stary kod był używany i testowany, a poprawki znalezionych w nim błędów to wiedza, która przy przepisaniu przepada.
Między tymi skrajnościami jest podejście, które Martin Fowler opisał jako Strangler Fig Application: nowy kod powstaje obok starego i stopniowo przejmuje kolejne funkcje, aż stary przestaje być potrzebny. Produkt działa przez cały czas, a każdy etap da się sprawdzić osobno. Dla MVP, które się sprawdziło, to zwykle najlepsza droga.
Rozwijać czy przepisać
| Sygnał | Co zwykle robić |
|---|---|
| Kod jest nieelegancki, ale zmiany są przewidywalne i nie psują innych miejsc | Rozwijać, porządkując przy okazji kolejnych zmian |
| Każda zmiana psuje coś w innym miejscu, a testów nie ma | Najpierw testy automatyczne głównej ścieżki, potem porządkowanie modułami |
| Model danych nie pasuje do potwierdzonej hipotezy, na przykład produkt zmienił grupę docelową | Przepisanie warstwy danych z migracją, reszta stopniowo |
| MVP powstało w narzędziu no-code i dochodzi do jego limitów | Budowa w kodzie od nowa, ale z zaplanowaną migracją danych i okresem równoległej pracy |
| Produkt jest wolny | Najpierw pomiar, bo przyczyną zwykle są konkretne zapytania lub brak indeksów, a nie wybór języka |
| Technologia przestała być wspierana albo nikt nie chce jej rozwijać | Stopniowa wymiana modułów, zaczynając od najczęściej zmienianych |
Jeden przypadek zasługuje na ostrzeżenie: przepisywanie produktu, zanim hipoteza została sprawdzona. Jeśli MVP jeszcze nie odpowiedziało na swoje pytanie, przepisanie kodu jest budową drugiego MVP bez żadnej nowej wiedzy. Kod przepisuje się wtedy, gdy wiadomo, co ma robić, a nie po to, żeby się tego dowiedzieć.
Gdy już wymieniasz część systemu, zachowaj adresy i interfejsy, z których korzystają użytkownicy i inne systemy, a dane przenoś najpierw na próbę, na kopii. Wymiana staje się wtedy serią małych, odwracalnych kroków, a nie jednym dniem, w którym wszystko musi zadziałać.
Kod, prawa i dokumentacja: żeby MVP dało się rozwijać z kimkolwiek
MVP, które się sprawdzi, będzie rozwijane latami, czasem przez inny zespół niż ten, który je zbudował. Dlatego niezależnie od tego, jak skromna jest pierwsza wersja, kilka rzeczy powinno należeć do Ciebie od początku:
- Kod w repozytorium, do którego masz dostęp. Z pełną historią zmian, a nie jako archiwum przekazane przy odbiorze.
- Autorskie prawa majątkowe do kodu. Przeniesione na Ciebie na piśmie, z wymienionymi polami eksploatacji.
- Konta w usługach na Twoje dane. Domena, serwer, operator płatności i usługa wysyłki maili.
- Dokumentacja. Jak uruchomić projekt od zera i wdrożyć zmianę, a obok tego hipoteza, lista "nie teraz" i powody kluczowych wyborów technicznych.
Brak którejkolwiek z tych rzeczy nie przeszkadza w dniu startu, ale bardzo przeszkadza, gdy chcesz zmienić wykonawcę, pozyskać inwestora albo sprzedać produkt. Każdy projekt kończymy przekazaniem pełnych praw do kodu i dokumentacji, żeby dalszy rozwój nie zależał od tego, kto napisał pierwszą wersję.
Najczęstsze pytania o MVP
Ile kosztuje MVP?
Tyle, ile kosztuje zbudowanie jednej ścieżki dla jednej grupy użytkowników, plus budżet na zmiany po starcie. Na kwotę najbardziej wpływają liczba ról użytkowników, płatności, integracje z innymi systemami i to, czy produkt musi być aplikacją w sklepie, czy wystarczy przeglądarka. Rzetelną wycenę dostaniesz, gdy wyślesz hipotezę, opis ścieżki i listę "nie teraz". Sama nazwa produktu i lista pomysłów nie wystarczą, bo każdy wykonawca wyceni wtedy inny zakres.
Ile trwa zbudowanie MVP?
Lepiej odwrócić pytanie: ustal datę, do której chcesz poznać odpowiedź, i dopasuj do niej zakres. Jeśli pierwsza wersja się w niej nie mieści, zwykle znaczy to, że zakres nie jest minimalny.
Czy MVP może wyglądać przeciętnie i mieć błędy?
Może wyglądać skromnie, ale nie może zawodzić na głównej ścieżce. Jeśli użytkownicy rezygnują, bo formularz płatności nie działa na telefonie, wynik mówi o błędzie, a nie o hipotezie.
Czy MVP potrzebuje regulaminu i polityki prywatności?
Jeśli świadczysz usługę drogą elektroniczną, regulamin jest obowiązkowy i musi być udostępniony przed zawarciem umowy. Jeśli zbierasz dane osobowe, obowiązuje Cię obowiązek informacyjny z RODO, a pliki cookies poza niezbędnymi wymagają zgody. Dokumenty mogą być krótkie, ale muszą odpowiadać temu, co produkt naprawdę robi.
Co zrobić, jeśli MVP się nie sprawdzi?
Ustal, które założenie zawiodło: problem, rozwiązanie, cena czy dotarcie. Od tego zależy, czy zmieniasz grupę, ścieżkę, cenę, czy kończysz projekt. Przy zmianie kierunku często da się wykorzystać sporą część kodu i danych z pierwszej wersji.
Od czego zacząć
Zanim poprosisz kogokolwiek o wycenę, zapisz na jednej stronie hipotezę z progiem i datą, grupę użytkowników, ścieżkę krok po kroku i listę "nie teraz" z powodami. Ta strona przyda się przy każdym wykonawcy, bo pozwala porównać oferty na tym samym zakresie.
Jeśli chcesz, żebyśmy spojrzeli na taki opis, wyślij go przez formularz kontaktowy. Budujemy oprogramowanie od 2020 roku, a to, jak wygląda współpraca od pierwszej rozmowy do wdrożenia, opisaliśmy na stronie jak pracujemy. Zakres usług dla platform internetowych znajdziesz w ofercie platform.
