Prototyp, MVP czy od razu pełny produkt? Jak zdecydować, od czego zacząć

Stan na 11.10.2026. Ten poradnik opisuje podejście, a nie przepisy, więc dat jest w nim niewiele. Źródła, na które się powołujemy, znajdziesz na dole strony.

Trzy etapy, trzy różne pytania

Najczęstszy błąd przy nowym produkcie to wybór etapu według budżetu albo ambicji, a nie według pytania, na które trzeba odpowiedzieć. Każdy etap odpowiada na inne pytanie:

Etap	Pytanie	Co powstaje
Prototyp	Czy ludzie rozumieją, jak z tego korzystać, i czy to rozwiązuje ich problem?	ekrany połączone w ścieżkę, którą można przeklikać
Test popytu	Czy ktoś tego chce na tyle, żeby zostawić adres albo zapłacić?	strona z ofertą i pomiar zapisów
MVP	Czy ludzie będą z tego korzystać i wracać?	pierwsza działająca wersja wokół jednej funkcji
Pełny produkt	Jak obsłużyć więcej użytkowników, przypadków i funkcji?	produkt rozwijany według planu

Jeśli nie umiesz jeszcze odpowiedzieć na pytanie z pierwszego wiersza, budowanie czegoś z ostatniego wiersza jest zakładem, a nie planem.

Prototyp: kiedy wystarczy

Klikalny prototyp wygląda jak aplikacja, ale nią nie jest. Nie zapisuje danych, nie przyjmuje płatności i nie ma logowania. Za to powstaje w dni, a nie w tygodnie, i można go zmienić w godzinę.

Rządowy podręcznik projektowania usług w Wielkiej Brytanii (GOV.UK Service Manual) opisuje ten etap jako czas na wypróbowanie różnych rozwiązań i sprawdzenie najbardziej ryzykownych założeń. Radzi budować rzeczy tylko na tyle złożone, żeby dało się przetestować pomysł, a nie kod produkcyjny. Zaznacza też, że po tym etapie można uczciwie zdecydować o zatrzymaniu projektu.

Prototyp wystarczy, gdy:

• masz pomysł, ale nie było jeszcze rozmów z przyszłymi użytkownikami;
• nie wiesz, którą z kilku ścieżek wybrać;
• chcesz pokazać pomysł wspólnikowi, inwestorowi albo zespołowi i mówić o konkretach, a nie o opisie;
• produkt ma nietypowy sposób działania i trzeba sprawdzić, czy ludzie go zrozumieją.

Co sprawdzić na prototypie:

• czy osoba z grupy docelowej przejdzie główną ścieżkę bez Twojej pomocy;
• gdzie się zatrzymuje, czego szuka, co rozumie inaczej, niż zakładano;
• czy opisuje problem, który prototyp rozwiązuje, jako swój;
• czego jej brakuje, a co jest zbędne.

Ile osób zaprosić. Jakob Nielsen z Nielsen Norman Group pisał w 2000 r., że pięć osób znajduje zwykle około 85% problemów z używaniem, i radził zrobić kilka małych rund testów zamiast jednej dużej. Zastrzegł przy tym, że dotyczy to podobnych użytkowników. Jeśli produkt ma dwie lub trzy różne grupy, np. klientów i usługodawców, potrzebujesz kilku osób z każdej grupy.

Czego prototyp nie powie. Nie sprawdzi, czy ludzie zapłacą, czy będą wracać i czy technicznie da się to zrobić w rozsądnym koszcie. Rozmówcy często są też uprzejmi. „Fajne, korzystałbym” to sygnał, a nie dowód.

Test popytu: zanim zapłacisz za kod

Między prototypem a MVP jest krok, który wiele zespołów pomija: sprawdzenie, czy ktoś w ogóle chce produktu. Najprostsza forma to strona z ofertą, która mówi wprost, że produkt dopiero powstaje, i zbiera zapisy na listę oczekujących. Do tego krótka kampania reklamowa i pomiar, ilu odwiedzających się zapisało.

To nie jest badanie naukowe, ale daje liczby zamiast opinii. Jeśli przy rozsądnym ruchu nikt się nie zapisuje, lepiej wiedzieć to przed budową. Pamiętaj tylko, żeby nie obiecywać na stronie rzeczy, których produkt nie będzie miał, i żeby poinformować o przetwarzaniu danych z formularza.

MVP: kiedy jest potrzebne

MVP to pierwsza wersja, z której mogą korzystać prawdziwi użytkownicy. Robi jedną rzecz dobrze. Wokół niej jest tylko to, bez czego produkt nie działa: logowanie, płatności, jeśli są potrzebne, panel administracyjny i analityka.

MVP ma sens, gdy:

• prototyp lub rozmowy potwierdziły, że problem jest prawdziwy, a rozwiązanie zrozumiałe;
• test popytu albo lista zainteresowanych pokazały, że ktoś na to czeka;
• kolejne pytania da się sprawdzić tylko na działającym produkcie: czy ludzie wracają, czy płacą, ile kosztuje obsługa jednego użytkownika.

Co mierzyć w MVP:

• ile osób, które się zarejestrowały, przeszło główną ścieżkę do końca;
• ile wróciło po tygodniu i po miesiącu;
• ilu zapłaciło, jeśli produkt jest płatny;
• ile kosztuje obsługa jednego aktywnego użytkownika, w tym usługi zewnętrzne i modele AI;
• co ludzie piszą w zgłoszeniach i o co pytają.

Ustal te miary przed startem. Po starcie łatwo uznać każdy wynik za sukces.

Produkt z AI to szczególny przypadek. Najważniejsze ryzyko brzmi tu: czy AI w ogóle da dobre odpowiedzi na Twoich danych i ile będzie to kosztować? Dlatego przed MVP warto zbudować krótkie demo na prawdziwych danych i zestaw pytań testowych. Klikalny prototyp tego nie sprawdzi.

Pełny produkt: kiedy od razu

Są sytuacje, w których MVP nie ma sensu:

• zastępujesz istniejący system firmy. Użytkownicy muszą z niego korzystać, a wymagania znasz z codziennej pracy. Ryzykiem nie jest to, czy ktoś tego chce, tylko czy przeniesiesz dane i procesy bez przestoju;
• przepisy wymagają pełnej funkcjonalności od pierwszego dnia, np. w produktach finansowych czy medycznych;
• masz podpisanych klientów, którzy zamówili konkretny zakres.

Nawet wtedy warto budować etapami i wdrażać części, zamiast czekać miesiącami na jeden duży start. Ale pytanie „czy ktoś tego chce” nie jest wtedy głównym ryzykiem.

Przykład: ten sam pomysł na trzech etapach

Założycielka chce zbudować aplikację, w której właściciele mieszkań na wynajem zamawiają sprzątanie między gośćmi.

• Prototyp. Kilkanaście ekranów: zamówienie sprzątania, wybór terminu, potwierdzenie. Pięć rozmów z właścicielami pokazuje, że nikt nie chce zamawiać ręcznie. Chcą, żeby sprzątanie zamawiało się samo po wymeldowaniu gościa. To zmienia cały produkt, a kosztowało kilka dni pracy.
• Test popytu. Strona z opisem „sprzątanie zamawia się samo” i lista oczekujących. Zapisy pokazują, czy właściciele są zainteresowani na tyle, żeby zostawić kontakt.
• MVP. Jedna funkcja: po wymeldowaniu z kalendarza obiektu powstaje zlecenie dla firmy sprzątającej. Bez czatu, ocen i aplikacji mobilnej. Miary: ile zleceń zostało wykonanych i ilu właścicieli zostało po miesiącu.

Typowe błędy

1. MVP z dwudziestoma funkcjami. Jeśli wszystko jest „konieczne na start”, to nie jest MVP. Wybierz jedną rzecz, dla której ktoś przyjdzie.
2. Rozmowy tylko ze znajomymi. Bliscy chcą Ci pomóc, więc chwalą. Szukaj osób z grupy docelowej, które nic Ci nie zawdzięczają.
3. Pytanie „czy skorzystałbyś?”. Lepiej pytać o przeszłość: jak dziś rozwiązujesz ten problem, ile Cię to kosztuje, kiedy ostatnio szukałeś lub szukałaś rozwiązania.
4. Aplikacja mobilna na start bez potrzeby. Aplikacja webowa działa w przeglądarce telefonu, powstaje szybciej i pozwala sprawdzić to samo. Mobilną buduj, gdy produkt potrzebuje funkcji telefonu.
5. Brak miar przed startem. Bez nich nie wiesz, czy MVP się udało, i decydujesz na podstawie wrażeń.
6. Prototyp traktowany jak gotowy produkt. Kod z etapu prób często się wyrzuca. To normalne i tańsze niż budowanie na nim produktu, który nie był do tego przygotowany.
7. Konta i domena na wykonawcy. Od pierwszego dnia zakładaj repozytorium, domenę i usługi na siebie. Zmiana wykonawcy będzie wtedy prosta.

Prosta ścieżka decyzji

• Masz tylko pomysł? Zacznij od rozmów i klikalnego prototypu.
• Prototyp się sprawdził, ale nie wiesz, czy ktoś zapłaci? Zrób test popytu.
• Masz zainteresowanych i wiesz, co zbudować? Zbuduj MVP wokół jednej funkcji.
• Produkt opiera się na AI? Najpierw demo na prawdziwych danych, potem MVP.
• Zastępujesz istniejący system albo masz podpisanych klientów? Planuj pełny produkt, ale wdrażaj go etapami.

Po każdym etapie możesz uczciwie zdecydować: idziemy dalej, zmieniamy kierunek albo zatrzymujemy projekt. Zatrzymanie po prototypie to też dobry wynik, bo kosztowało dużo mniej niż MVP.

Jak pracujemy w MEZA Startups

Każdy etap ma u nas osobną umowę i stałą cenę, więc po każdym możesz zdecydować, co dalej:

• klikalny prototyp z warsztatem i rozmowami z użytkownikami;
• test popytu z landingiem i kampanią testową, opisany na stronie MEZA Startups;
• MVP aplikacji webowej, z tygodniem ustalania zakresu przed stałą ceną budowy;
• AI MVP, w którym najpierw powstaje demo na Twoich danych.

Ile może kosztować MVP i od czego zależy cena, opisaliśmy w poradniku Ile kosztuje MVP aplikacji w 2026 roku. Wycenę pierwszego etapu dostaniesz w ciągu 24 godzin, także w weekendy i święta.