MVP — co to jest i jak wyciąć z pomysłu wersję, która odpowie na jedno pytanie

Większość projektów nazwanych „MVP” to pełne aplikacje z uciętym budżetem. Ktoś ma listę trzydziestu funkcji, wykonawca wycenia ją na kwotę, której nie ma, i obie strony zgadzają się „zacząć od MVP” — czyli od tych samych trzydziestu funkcji, zrobionych szybciej i taniej. Po kilku miesiącach powstaje produkt, który niczego nie sprawdził, bo nikt nie ustalił, co miał sprawdzić.

MVP to coś innego. To najmniejszy produkt, który odpowiada na jedno pytanie biznesowe — i zakres wyznacza właśnie to pytanie, a nie budżet. Dlatego najtrudniejszą częścią pracy nad MVP nie jest programowanie, tylko spisanie, czego nie budujemy. Ten tekst pokazuje, jak to zrobić: czym MVP różni się od proof of concept i prototypu, jak wyciąć zakres metodą MoSCoW, jaką miarą sprawdzić wynik i jak wygląda rozbudowa, kiedy wynik już jest. Przykłady pochodzą z narzędzi, które zbudowaliśmy dla siebie — z datami, bo te da się sprawdzić.

Co to jest MVP (minimum viable product)

Skrót MVP pochodzi od angielskiego minimum viable product. Pojęcie spopularyzował Eric Ries, autor metodyki lean startup, i jego definicja jest do dziś najczęściej cytowana: to „ta wersja nowego produktu, która pozwala zespołowi zebrać najwięcej potwierdzonej wiedzy o klientach przy najmniejszym wysiłku” (Eric Ries, „Minimum Viable Product: a guide”, 2009).

W tej definicji ważne są dwa słowa. Pierwsze to wiedza — MVP nie jest produktem do sprzedania w pierwszej kolejności, tylko narzędziem do sprawdzenia założenia. Drugie to viable, które w polskich tekstach bywa tłumaczone jako „opłacalny”. To błąd, który zmienia sens całego pojęcia. Viable znaczy „zdolny do działania”, „realny” — MVP musi naprawdę działać w rękach prawdziwych użytkowników. Makieta, prezentacja czy ankieta mogą być dobrym pierwszym krokiem, ale nie są MVP, bo niczego nie pozwalają zmierzyć w użyciu.

Lean startup: zbuduj, zmierz, wyciągnij wniosek

Lean startup, z którego pochodzi pojęcie, to podejście oparte na krótkiej pętli: zbuduj najmniejszą rzecz, zmierz, jak ludzie jej używają, wyciągnij wniosek i zdecyduj, co dalej. MVP jest pierwszym obrotem tej pętli. Jeśli po nim nie zapada żadna decyzja, to znaczy, że pętla się nie zamknęła.

Decyzje po pomiarze są w praktyce trzy. Można rozwijać — wynik potwierdził założenie, więc następny obrót pętli dokłada kolejną funkcję i kolejne pytanie. Można zmienić kierunek — ludzie używają produktu, ale inaczej, niż zakładaliście, i to jest cenniejsza informacja niż potwierdzenie; w żargonie lean startup nazywa się to pivotem. Można wreszcie zakończyć — i to też jest dobry wynik, jeśli kosztował kilka tygodni zamiast roku. MVP, po którym żadna z tych trzech decyzji nie jest możliwa, bo wynik „trochę tak, trochę nie”, zwykle nie miało spisanej miary.

Ta pętla działa tylko wtedy, gdy obrót jest krótki. Dlatego ograniczeniem MVP nie jest budżet, tylko czas do pierwszego pomiaru: im szybciej prawdziwi użytkownicy dostaną coś działającego, tym szybciej dowiecie się, czy warto budować resztę.

MVP, proof of concept i prototyp — trzy różne pytania

W rozmowach o nowym produkcie te trzy słowa padają zamiennie, a każde oznacza inny wydatek i inny wynik. Najprościej rozróżnić je po pytaniu, na które odpowiadają:

Proof of concept ma sens tam, gdzie największe ryzyko jest techniczne: nie wiadomo, czy integracja z systemem dostawcy w ogóle jest możliwa albo czy algorytm poradzi sobie z danymi. Prototyp — tam, gdzie ryzykiem jest wygoda użycia; jak wygląda i co z niego wynika, opisujemy w tekście o procesie tworzenia aplikacji. MVP — tam, gdzie ryzykiem jest to, czy ktoś tego w ogóle potrzebuje. Te trzy kroki mogą iść po kolei, ale żaden nie zastępuje pozostałych.

Jedna uwaga o nazwie, bo „proof of concept” ma w Polsce drugie znaczenie. Fundacja na rzecz Nauki Polskiej prowadzi program o tej nazwie w ramach FENG, ale jest on skierowany do organizacji badawczych, które chcą sprawdzić potencjał wdrożeniowy wyników badań — nie do firm budujących produkt (FNP, Proof of Concept). Jeśli szukacie finansowania na MVP aplikacji, to nie jest ten program.

Czego MVP nie jest

Łatwiej zrozumieć MVP przez to, czym nie jest, bo trzy najczęstsze pomyłki powtarzają się w niemal każdym projekcie.

MVP to nie niedokończona aplikacja. Wersja, w której połowa ekranów jest pusta, a druga połowa działa „prawie”, nie da wiarygodnej odpowiedzi — użytkownik odrzuci ją z powodu braków, a nie dlatego, że pomysł jest zły. MVP ma mały zakres, ale w tym zakresie działa dobrze.

MVP to nie beta pełna błędów. Błędy w MVP są tak samo drogie jak w pełnej wersji, bo psują pomiar: nie wiadomo, czy ktoś zrezygnował, bo nie potrzebował funkcji, czy dlatego, że się zawiesiła.

MVP to nie „wszystko, tylko taniej”. Obniżenie jakości przy tym samym zakresie nie jest wersją minimalną, tylko gorszą wersją pełną. Oszczędność w MVP bierze się z wycięcia funkcji, a nie z pośpiechu.

MVP nie zawsze musi być aplikacją

Skoro MVP ma odpowiedzieć na pytanie, a nie wyglądać na produkt, część jego pracy może wykonywać człowiek. Taki wariant nazywa się czasem concierge MVP: użytkownik widzi prosty formularz albo panel, a to, co za nim ma się dziać automatycznie, na początku robi ktoś z zespołu ręcznie. Pomiar jest ten sam — czy ludzie z tego korzystają — a koszt wielokrotnie niższy, bo najdroższa część, czyli automatyzacja, powstaje dopiero wtedy, gdy wiadomo, że jest potrzebna.

Nasz własny moduł rezerwacji rozmów zaczynał dokładnie tak, o czym niżej: formularz z datą i ręczne potwierdzanie terminu. Dla użytkownika działał — umawiał rozmowę. Dla nas był odpowiedzią na pytanie, czy umawianie przez stronę w ogóle ma sens, zanim zapłacimy za silnik wolnych terminów.

Ten wariant ma granicę: ręczna praca musi dać się utrzymać przy skali, jakiej MVP potrzebuje do pomiaru. Kilkanaście zgłoszeń tygodniowo — tak. Kilkaset dziennie — nie, i wtedy automatyzacja przestaje być kosztem na zapas, a staje się warunkiem.

Metoda MoSCoW — jak wyciąć zakres

Najbardziej praktycznym narzędziem do cięcia zakresu jest metoda MoSCoW. To technika priorytetyzacji, w której każde wymaganie trafia do jednej z czterech kategorii. Agile Business Consortium, organizacja rozwijająca metodykę DSDM, opisuje je tak (Agile Business Consortium, MoSCoW Prioritisation):

• Must have — minimalny użyteczny zestaw wymagań, który projekt gwarantuje dostarczyć;
• Should have — ważne, ale nie niezbędne;
• Could have — pożądane, ale mniej ważne;
• Won't have this time — wymagania, co do których zespół uzgodnił, że nie zostaną dostarczone w tym okresie.

W MVP kategoria Must ma być tak mała, jak to możliwe — tylko to, bez czego nie da się odpowiedzieć na pytanie. Kategoria Won't jest równie ważna i najczęściej pomijana. Jeśli nie zapiszecie, czego świadomie nie budujecie, te funkcje wrócą w trakcie projektu jako „drobne dodatki”, i po trzech miesiącach MVP znów będzie pełną aplikacją.

Jak przeprowadzić MoSCoW na własnej liście

Zacznijcie od spisania wszystkich funkcji, o których ktokolwiek w firmie wspomniał — bez oceniania. Potem przejdźcie przez listę z jednym pytaniem przy każdej pozycji: czy bez tej funkcji da się odpowiedzieć na pytanie, dla którego budujemy MVP? Jeśli nie — Must. Jeśli tak, ale produkt będzie wyraźnie gorszy — Should. Jeśli tak i różnicę zauważy niewielu — Could. Wszystko, co zostanie, trafia do Won't, z datą, kiedy do tego wrócicie.

Dwie reguły pilnują, żeby podział nie był fikcją. Pierwsza: kategoria Must nie może być najliczniejsza — jeśli jest, to znaczy, że każdy obronił swoją funkcję i nic nie zostało wycięte. Druga: listę Won't podpisuje ta sama osoba, która akceptuje budżet. Wtedy funkcja, która wraca w trakcie projektu, wraca z pytaniem, co w zamian wypada, a nie jako „mały dodatek”.

Przykład: zakres pierwszej wersji naszego CRM

Kiedy w lipcu 2026 roku budowaliśmy własny CRM — bazę kontaktów, do której trafia każde zapytanie z tej strony — spisaliśmy zakres dokładnie w tych kategoriach, choć pod innymi nazwami: „faza 0”, „później, zachowane, nie odrzucone” i „świadomie tego nie robimy”. Po dwóch miesiącach widać, co się z każdą pozycją stało:

Dwie rzeczy z tej tabeli są ważniejsze niż sam podział. Po pierwsze, pozycja z kategorii Could powstała dopiero wtedy, gdy pojawił się konkretny powód, a nie wtedy, gdy wydawała się przydatna. Po drugie, jedna pozycja nie powstała nigdy — i to też jest wynik: gdyby weszła do pierwszej wersji, zapłacilibyśmy za rozwiązanie problemu, którego nie ma. Jak podobne decyzje wyglądają przy wyborze między gotowym systemem a własnym, opisujemy w tekście o CRM dla małej firmy.

Jedno pytanie, jedna miara

Zakres to połowa MVP. Druga połowa to miara — i to ona odróżnia MVP od wersji, która „się udała”, bo nikt nie sprawdził, czy się udała.

Zanim ruszy budowa, zapiszcie trzy rzeczy. Pytanie: jedno zdanie, na które MVP ma odpowiedzieć, na przykład „czy nasi klienci będą składać zamówienia sami, zamiast dzwonić”. Miarę: liczbę, która na to odpowie, na przykład odsetek zamówień złożonych przez panel w pierwszym miesiącu. Próg: wartość, powyżej której uznajecie założenie za potwierdzone, a poniżej — za obalone. Do tego termin pomiaru, bo MVP bez daty odczytu nigdy się nie kończy.

Próg musi być spisany przed startem. Po fakcie każdy wynik da się przedstawić jako obiecujący — dwadzieścia procent to „już co piąty klient”, a pięć procent to „dobry początek”. Spisany wcześniej próg odbiera tę swobodę i właśnie dlatego jest potrzebny.

Product-market fit — kiedy MVP przestaje być MVP

Kiedy miara przez dłuższy czas rośnie bez dopychania — klienci wracają, polecają, a zapytania przychodzą same — mówi się o product-market fit, czyli dopasowaniu produktu do rynku. MVP nie ma tego udowodnić. Ma pokazać, czy warto w tę stronę iść, i uczciwie powiedzieć, kiedy nie warto.

Nie podajemy progu, od którego zaczyna się product-market fit, bo krążące w sieci liczby opisują produkty konsumenckie i start-upy technologiczne, a nie narzędzie dla firmy. Sygnały są jednak czytelne bez progów. Pierwszy: użytkownicy wracają bez przypominania — w aplikacji dla klientów widać to w powtórnych logowaniach, w narzędziu wewnętrznym w tym, że stary sposób pracy przestaje być używany. Drugi: prośby o nowe funkcje dotyczą rozszerzenia tego, co jest, a nie naprawienia podstaw. Trzeci: gdyby produkt zniknął, ktoś by zaprotestował.

Kiedy te sygnały się pojawiają, MVP przestaje być eksperymentem i staje się produktem. Wtedy zmienia się też sposób pracy: zamiast jednego pytania i jednej miary pojawia się plan rozwoju, a zamiast najmniejszego zakresu — zakres, który trzeba utrzymać, testować i rozbudowywać bez psucia tego, co działa.

Po MVP: rozbudowa wtedy, gdy jest powód

Najdroższy błąd po MVP to plan rozbudowy spisany pierwszego dnia i realizowany bez względu na to, co pokazał pomiar. Kolejne funkcje warto dokładać wtedy, gdy użycie ich wymaga — i to widać na historii modułu, przez który umawia się rozmowę na tej stronie.

Pierwsza wersja z grudnia 2024 roku była formularzem z datą: imię, e-mail, temat, wiadomość, początek i koniec spotkania — oraz pole „potwierdzone”, które zaznaczaliśmy ręcznie. Nie było w niej wolnych terminów, kalendarza ani automatycznego potwierdzenia. Odpowiadała na jedno pytanie: czy ludzie w ogóle będą umawiać rozmowę przez stronę, zamiast pisać maila.

Automatyczne terminy, uwzględnianie świąt, odwoływanie i przekładanie wizyt oraz połączenie z Kalendarzem Google przyszły w czerwcu 2026 roku — ponad półtora roku później, kiedy ręczne potwierdzanie zaczęło kosztować więcej niż jego zautomatyzowanie. Wcześniej ta sama praca byłaby budowaniem odpowiedzi na pytania, których jeszcze nikt nie zadał.

Podobnie było z kalkulatorem kosztu aplikacji webowej i jego odpowiednikami: w marcu 2026 roku ruszyły z trzema konfiguracjami — strona, sklep i aplikacja webowa. Dziś jest ich osiem, a każda kolejna doszła dopiero wtedy, gdy pierwsze trzy pokazały, że narzędzie jest używane.

Ile trwa i ile kosztuje MVP

Na oba pytania uczciwa odpowiedź brzmi: tyle, ile kategoria Must. Dlatego nie podajemy tu własnych widełek — każda para liczb bez zakresu jest zgadywaniem.

Jest jednak punkt odniesienia. W naszym raporcie kosztów aplikacji webowych mediana ceny MVP wynosi 30 000 zł, przy 24 obserwacjach; połowa wycen mieści się między 22 500 a 50 000 zł. To ceny z publicznych cenników i ofert, a nie z podpisanych umów — ale jeśli dostajecie wycenę MVP na kilka tysięcy złotych, to prawdopodobnie kupujecie coś innego niż działający produkt, na przykład prototyp. Jak czytać takie wyceny i z czego składa się cena, rozpisujemy w tekście ile kosztuje stworzenie aplikacji.

Z czasem jest podobnie. Każda funkcja z kategorii Must dokłada swój kawałek harmonogramu, a niektóre dokładają dużo — w naszych regułach planowania sama strefa klienta z logowaniem to dodatkowe dwa do czterech tygodni. Ważniejsza od daty „gotowości” jest jednak data pomiaru: dzień, w którym odczytacie miarę i podejmiecie decyzję. Ją ustalcie przed startem razem z progiem.

Jeśli szukacie publicznego finansowania, zachowajcie ostrożność. Program Proof of Concept jest przeznaczony dla nauki, a ścieżki dla przedsiębiorstw, które sprawdziliśmy, dotyczą znacznie większych projektów wdrożeniowych. Nie znaleźliśmy programu, który w 2026 roku finansowałby firmie samo MVP aplikacji.

Checklista zakresu MVP