MVP aplikacji webowej — jak je zbudować i nie przepalić budżetu
MVP aplikacji webowej to najmniejsza wersja produktu, która pozwala prawdziwym użytkownikom wykonać jedną kluczową czynność od początku do końca i sprawdzić, czy ktoś chce za to zapłacić. Dobrze zakrojone MVP powstaje zwykle w kilka do kilkunastu tygodni. Najwięcej budżetu przepala się na funkcje, które nie służą sprawdzeniu tej jednej hipotezy, oraz na decyzje odłożone na później, takie jak role i uprawnienia, które doklejone po fakcie kosztują wielokrotnie więcej.
Większość briefów na MVP, które dostaję, nie opisuje MVP. Opisuje pełny produkt w wersji, którą założyciel widzi za dwa lata, z dopiskiem „ale na początek wystarczy prościej”. Wycena takiego briefu jest zawsze za wysoka, a termin zawsze za długi — i to nie jest wina wyceniającego.
Poniżej to, czego nauczyłem się przy budowaniu pierwszych wersji produktów: co powinno wejść, co nie powinno i gdzie budżet znika najszybciej.
Czym MVP jest, a czym nie jest
MVP to nie jest „aplikacja, tylko brzydsza”. To najmniejsza rzecz, która pozwala odpowiedzieć na jedno pytanie: czy ktoś tego naprawdę używa i czy za to zapłaci.
Jeśli funkcja nie pomaga odpowiedzieć na to pytanie, nie wchodzi do MVP. Nawet jeśli jest prosta. Nawet jeśli „wszyscy konkurenci to mają”.
Dobry test: opisz w jednym zdaniu, co użytkownik robi w Twojej aplikacji od wejścia do momentu, w którym dostał wartość. Na przykład: „właściciel gabinetu dodaje wolne terminy, a pacjent rezerwuje jeden z nich i dostaje potwierdzenie”. To zdanie jest zakresem MVP. Wszystko poza nim to druga wersja.
Co zwykle wypada z pierwszej wersji
To są rzeczy, które w briefach pojawiają się najczęściej, a w MVP prawie nigdy nie są potrzebne:
- panel statystyk — w pierwszych tygodniach liczby czyta się prosto z bazy albo z narzędzia analitycznego
- aplikacja mobilna obok webowej — dobrze zrobiona aplikacja webowa działa na telefonie, a sklepy z aplikacjami to osobny koszt i osobny proces publikacji
- logowanie przez pięciu dostawców — e-mail plus jeden, którego używa Twoja grupa docelowa, wystarczy
- powiadomienia o wszystkim — na start jeden mail w kluczowym momencie
- automatyczne fakturowanie — przy pierwszych dziesięciu klientach faktury da się wystawić ręcznie
- wielojęzyczność — chyba że pierwszy rynek naprawdę jest wielojęzyczny
Każda z tych rzeczy osobno wygląda na drobiazg. Razem potrafią podwoić zakres.
Czego nie odkładać na później
Jest też druga strona. Niektóre decyzje kosztują niewiele na starcie i bardzo dużo, jeśli zostaną odłożone:
Role i uprawnienia. Kto co widzi i kto co może zmienić. Jeśli w produkcie kiedykolwiek będą zespoły, organizacje albo różne typy kont, model danych trzeba zaprojektować pod to od początku — nawet jeśli w MVP jest tylko jeden typ użytkownika. Doklejenie tego po fakcie potrafi kosztować tyle, co połowa systemu.
Struktura danych. Interfejs da się przebudować w tydzień. Migracja danych prawdziwych użytkowników ze złego modelu na dobry to tygodnie i ryzyko.
Własność kodu i infrastruktury. Repozytorium, hosting, domena i konta usług zewnętrznych powinny być na Ciebie od pierwszego dnia. Przy inwestorze to jedno z pierwszych pytań w due diligence. Więcej o tym w tekście o własności domeny i kodu.
Analityka kluczowego zdarzenia. Jeśli MVP ma odpowiedzieć na pytanie, czy ktoś tego używa, musisz od pierwszego dnia wiedzieć, ile osób doszło do końca kluczowej ścieżki.
Jak wycenia się MVP
Aplikacji nie da się uczciwie wycenić z tabeli, bo o cenie decyduje proces, który mają obsłużyć, a nie liczba ekranów. Dlatego wyceniam je indywidualnie, po rozpisaniu zakresu — i to rozpisanie jest bezpłatne.
To, co realnie przesuwa koszt:
| Co | Dlaczego podnosi cenę |
|---|---|
| Liczba typów użytkowników | Każdy typ to osobne ścieżki, widoki i uprawnienia |
| Płatności i subskrypcje | Obsługa nieudanych płatności, zmian planu, faktur |
| Integracje z zewnętrznymi systemami | Zależą od jakości ich API, nie od Ciebie |
| Funkcje działające w czasie rzeczywistym | Czat, współpraca na żywo, powiadomienia natychmiastowe |
| Import istniejących danych | Dane z Excela prawie nigdy nie są tak czyste, jak się wydaje |
Etapy zamiast jednego wielkiego wdrożenia
Nie znikam na pół roku, żeby wrócić z gotowym systemem. Pierwszy etap to jedna kompletna funkcja, której realnie zaczynacie używać — z prawdziwymi użytkownikami, nie na prezentacji. Dopiero po ich reakcji dokładamy następną.
To ma dwie zalety. Widzisz efekt po kilku tygodniach, a nie po kilku miesiącach. I możesz zmienić kierunek, zanim zostanie zbudowane wszystko, czego użytkownicy wcale nie potrzebowali. Płatność idzie w tym samym rytmie co etapy.
Freelancer czy software house
Przy MVP to pytanie wraca częściej niż przy stronach. Krótko: jedna osoba ma sens, gdy zakres jest dobrze zakrojony, a Tobie zależy na bezpośrednim kontakcie i szybkich decyzjach. Zespół ma sens, gdy od pierwszego dnia równolegle powstają aplikacja webowa, mobilna i rozbudowany backend. Szerzej rozpisałem to w tekście freelancer czy agencja.
Od czego zacząć
Zanim napiszesz do kogokolwiek, spisz trzy rzeczy: kto jest pierwszym użytkownikiem, jaką jedną czynność ma wykonać od początku do końca i po czym poznasz, że MVP zadziałało. Z tymi trzema odpowiedziami wycena jest dużo dokładniejsza — i zwykle dużo niższa.
Szczegóły tego, jak buduję aplikacje, opisałem na stronie aplikacje webowe. Jeśli masz pomysł i chcesz go rozpisać na zakres — napisz, odpowiadam w ciągu doby.
- aplikacje webowe
- startupy
- współpraca