Inwestor prosi o produkt, nie o prezentację
Masz deck, model finansowy i listę funkcji, a rozmowa z inwestorem kończy się jednym pytaniem: czy da się to kliknąć. Bez działającej wersji — nie ma drugiego spotkania.
MVP dla startupu — od pomysłu do działającego produktu
Budujemy pierwszą działającą wersję produktu z funkcjami potrzebnymi do weryfikacji hipotezy. Zakres, termin i cena ustalone przed startem, nie po drodze.
Z czym przychodzą do nas founderzy
Poprzedni zespół budował wszystko naraz
Lista funkcji rosła po każdym spotkaniu, bo zakres nigdy nie został zamknięty, a premiera przesuwała się co miesiąc. Pół roku pracy — i ani jednego użytkownika.
Budżet jest jeden i nie wiadomo, co za niego wejdzie
Wysyłasz jedno zapytanie i dostajesz wyceny, które różnią się kilkukrotnie, bo każda opisuje inny zakres. Budżet masz jeden — a wybierasz w ciemno.
Co wchodzi w MVP
Warsztat zakresu
Hipoteza do sprawdzenia i zamknięta lista funkcji v1
Klikalny prototyp
Ekrany połączone przejściami, przed pierwszą linijką kodu
Projekt interfejsu
Ekrany produkcyjne ze stanami pustym, błędu i ładowania
Rozwój produktu
React, TypeScript, backend, baza danych, API i integracje
Testy scenariuszy
Całe ścieżki użytkownika na przeglądarkach i urządzeniach
Wdrożenie i analityka
Produkcja, domena, monitoring i zdarzenia w kluczowych krokach
Wychodzisz z produktem, kodem i wszystkimi dostępami
- Kod źródłowy w Twoim repozytorium
- Wdrożone środowisko produkcyjne pod Twoją domeną
- Dostępy do serwerów, bazy danych i usług zewnętrznych
- Dokumentacja architektury i instrukcja wdrożenia
- Podpięta analityka ze zdarzeniami w kluczowych krokach ścieżki
- Lista funkcji odłożonych do v2 wraz z uzasadnieniem każdej decyzji
Jak przebiega praca
Warsztat zakresu
2–3 dniRozkładamy pomysł na jedną hipotezę i ścieżkę użytkownika, która ją weryfikuje. Dzielimy funkcje na v1 i odłożone, a przy każdej odłożonej zapisujemy powód, żeby po premierze było wiadomo, do czego wracać.
Prototyp i stała wycena
3–5 dniSkładamy klikalny prototyp głównej ścieżki i wyceniamy zamknięty zakres. Od akceptacji tej wyceny liczy się termin 3–5 tygodni — dlatego nie podajemy go, zanim nie wiemy, co budujemy.
Projekt ekranów
3–5 dniProjektujemy ekrany uzgodnionej ścieżki wraz ze stanem pustym, błędem i wersją mobilną. Równolegle ustalamy architekturę, model danych i miejsca integracji, żeby budowa nie zatrzymała się na decyzji technicznej.
Rozwój
2–3 tygodnieKodujemy frontend, backend i integracje, a wynik co tydzień wykładamy na środowisko testowe. Widzisz działający produkt w trakcie prac i zgłaszasz uwagi, zanim funkcja trafi na kolejne ekrany.
Testy i poprawki
3–5 dniTestujemy całe scenariusze według kryteriów odbioru ustalonych razem z zakresem, na przeglądarkach i telefonach. Poprawiamy błędy, przygotowujemy dane startowe i treść komunikatów, które użytkownik zobaczy pierwszego dnia.
Wdrożenie i przekazanie
2–3 dniWdrażamy produkt na produkcję: domena, certyfikat, monitoring i analityka. Przekazujemy dostępy, dokumentację architektury oraz listę funkcji odłożonych do kolejnej wersji, razem z powodem każdej decyzji.
MVP a pełna wersja
Obie drogi mają sens — w różnych sytuacjach. Poniżej to, co realnie się między nimi zmienia.
| Pełna wersja od razu | MVP | |
|---|---|---|
| Zakres funkcji | Cała lista z warsztatów i rozmów z inwestorem, łącznie z tym, czego nikt jeszcze nie sprawdził | Jedna główna ścieżka użytkownika i funkcje, bez których nie da się jej przejść ani zmierzyć |
| Czas do pierwszych użytkowników | Miesiące — pierwsi użytkownicy widzą produkt na samym końcu prac | 3–5 tygodni od akceptacji zakresu i wyceny |
| Co jest ustalone przed startem | Zakres rośnie w trakcie prac, więc termin i koszt znasz dopiero po drodze | Zamknięta lista funkcji v1, termin i stała cena — wszystko uzgodnione przed pierwszą linijką kodu |
| Co weryfikujesz | Wszystko naraz — po premierze trudno powiedzieć, która funkcja zadziałała | Jedną hipotezę — wiadomo, co dokładnie sprawdzasz i po czym poznasz wynik |
| Koszt zmiany kierunku | Wysoki: przepisujesz gotowe, przetestowane moduły | Niski: zmieniasz plan i listę funkcji, a nie kilka miesięcy kodu |
| Czym ryzykujesz | Wydajesz budżet na funkcje, których nikt nie użyje, i dowiadujesz się o tym najpóźniej | Część funkcji czeka; jeśli hipoteza się potwierdzi, dobudowujesz je do istniejącego kodu |
| Kiedy wybrać | Znasz proces, masz płacących klientów albo twarde wymagania — na przykład regulacyjne | Sprawdzasz pomysł, budżet jest ograniczony, produkt jest potrzebny na rozmowę z inwestorem |
Na czym budujemy
- React
- TypeScript
- Backend dobierany do projektu
- Baza danych i API
- Stripe (płatności)
- LLM (funkcje AI)
- Wdrożenie i monitoring
Produkty, które doprowadziliśmy do premiery
Najczęstsze pytania o MVP
Ile kosztuje MVP aplikacji?
Po warsztacie zakresu, razem z klikalnym prototypem. Na kwotę wpływa liczba ekranów i ról, integracje zewnętrzne oraz to, czy w v1 jest też wydanie mobilne. Po akceptacji cena jest stała.
Ile trwa budowa MVP?
3–5 tygodni po ustaleniu zakresu — od momentu, w którym akceptujesz listę funkcji v1 i wycenę. Warsztat i prototyp zajmują wcześniej około tygodnia.
Co wchodzi w zakres MVP, a co odkładamy?
Jedna główna ścieżka użytkownika i funkcje, bez których nie da się jej przejść ani zmierzyć. Odkładamy role poza pierwszymi dwiema, panel administracyjny, płatności przed pierwszym klientem i wydania natywne.
Czy MVP da się rozbudować do pełnej wersji?
Tak. Budujemy tym samym stackiem co pełne produkty: React, TypeScript i backend dobrany do projektu. Odkładamy funkcje, a nie jakość kodu — kolejne role i integracje dokładamy do istniejącej bazy.
Pracujecie w modelu fixed price czy time & material?
Fixed price za zamknięty zakres — dlatego tyle uwagi poświęcamy warsztatowi przed startem. Rozwój po premierze rozliczamy miesięcznie albo kolejnymi etapami w stałej cenie.
Co jeśli po testach trzeba zmienić kierunek?
To normalny wynik pierwszej wersji — MVP ma dostarczyć dane, a nie potwierdzić założenia. Wracamy do listy hipotez i wyceniamy nowy zakres osobno. Zmieniasz plan, a nie miesiące kodu.
Czy pomagacie z wyborem funkcji do pierwszej wersji?
Tak, od tego zaczynamy. Na warsztacie działa jedno kryterium: funkcja zostaje w v1, jeśli bez niej nie da się przejść głównej ścieżki albo zmierzyć hipotezy. Reszta trafia na listę odłożonych.