Dlaczego MVP w 6 tygodni nie jest mitem

Wprowadzenie

„MVP w 6 tygodni? Nie da się” — to najczęstszy zarzut wobec takiej obietnicy. Da się — jeśli zrozumiesz, że MVP to nie wersja okrojona twojej wizji. To najmniejsza wersja, która dostarcza wartość użytkownikowi.

To jest dokładnie ta sama wartość, tylko mniejszym zakresem. Użytkownik płaci, używa, widzi działający produkt — wcześniej. Ty masz feedback w 8. tygodniu, nie w 8. miesiącu. Cała branża product managementu zbudowała się na tej obserwacji 20 lat temu — i wciąż jest aktualna.

W tym artykule trzy zasady, którymi tnę zakres MVP, plus konkretna lista co MUSI być i co wycinam ze spec’u.

Dlaczego „MVP” zwykle trwa 6 miesięcy

Bo „MVP” nazywa się coś, co jest v1 produktem. Lista pod tym szyldem wygląda zwykle tak:

• dashboard,
• panel admina,
• eksport do Excela,
• integracja z BLIK,
• notyfikacje push,
• dark mode,
• analityka zachowań.

To nie jest MVP. To jest minimum viable v1.

Trzy pułapki, które widać w projektach określanych jako „MVP”:

Pułapka 1: Spec to nie produkt

Typowa specyfikacja ma dwadzieścia stron i opisuje finalny stan produktu, nie pierwszą wersję. Sukces MVP zależy od umiejętności wycięcia grubo ponad połowy spec’u i nazwania tego „iteracją 2”. Reguła kciuka, którą stosuję: około 60%.

To nie jest oszustwo wobec zamawiającego — to definicja MVP. Musi o tym wiedzieć przed podpisaniem umowy. Jeśli się nie zgadza, nie robimy MVP, tylko pełniejszą pierwszą wersję: większy zakres, dłuższy termin, inny budżet. Obie drogi są OK; nie obiecuję niemożliwego.

Pułapka 2: „Może później” = nigdy

Każdy projekt ma listę funkcji oznaczonych „może później”. W praktyce „później” znaczy „nigdy”. Bo gdy MVP wystartuje i pojawią się pierwsi użytkownicy, okaże się, że prawdziwe potrzeby są inne niż te z listy „może później”.

Reguła: jeśli funkcja jest na liście „może później”, lepiej ją zostawić na liście pomysłów, nie w backlogu. Ułatwia to decyzje w iteracji 2 — wracasz do realnych potrzeb użytkowników, nie do starego dokumentu.

Pułapka 3: Chowanie wymagań na potem

Najgorsza wersja brzmi: „dasz radę bez płatności? Dorobimy to w v2”. A potem pierwsi użytkownicy nie mają jak zapłacić. MVP musi pokrywać CAŁY flow wartości — od rejestracji do otrzymania wartości (lub zapłaty za nią). Jeśli flow ma dziurę — MVP jest niewdrożony.

To inna pułapka niż „może później”. „Może później” dotyczy funkcji poza core flow. Chowanie wymagań na potem dotyczy funkcji w core flow. Pierwszą wycinamy świadomie, drugą — nigdy.

3 zasady MVP w 6 tygodni

Trzy zasady, które trzymam niezależnie od branży:

Zasada 1: Jeden flow użytkownika

Pierwsza iteracja obsługuje jedną personę × jeden core flow. Nie 3 persony i 5 flow’ów. Jeden. Wszystko inne to backlog na iterację 2.

Weźmy przykład (hipotetyczny) — produkt SaaS dla agencji marketingowych z listą życzeń:

• dashboard dla klienta końcowego,
• dashboard dla agencji,
• dashboard dla admina,
• raport PDF,
• eksport do Excela.

Do MVP wchodzi jeden panel — ten dla agencji — bo agencja płaci, agencja decyduje, agencja jest pierwszym użytkownikiem. Pozostałe cztery to kandydaci do iteracji 2, weryfikowani realnym feedbackiem, a nie listą z pierwszego spotkania.

Zasada 2: Jedna platforma

Web ALBO mobile ALBO desktop — nie wszystko naraz w iteracji 1. Cross-platform to wielokrotność czasu, nie dodatek do niego.

W większości webowych MVP odpowiedzią jest PWA na webie. Działa na każdym urządzeniu, deploy zajmuje minuty, nie wymaga app store’a, można iterować bez review process. Mobile native (React Native, Flutter) zostawiam na iterację 2 — jeśli user research powie, że jest potrzebny.

Zasada 3: Jeden integration point

MVP integruje się z maksymalnie jednym systemem zewnętrznym. Płatności? Tak. ALBO SSO Google. ALBO sync z CRM. Nie wszystko naraz.

Każda integracja to zwykle 3–5 dni pracy (research API, implementacja, edge case’y, retry logic, monitoring). Trzy integracje to już około dwóch tygodni samego spinania systemów. Wycięcie do jednej oddaje ten czas na core flow — bez utraty wartości MVP.

Co MUSI być w MVP — checklist

Niezależnie od projektu sześć rzeczy zawsze zostaje:

Element	Co konkretnie	Dlaczego zostaje
Auth	Login, reset hasła, sesja	Bez tego nie ma płatności
Core flow	End-to-end: rejestracja → wartość	Inaczej to demo, nie produkt
Deploy	Produkcyjny URL, HTTPS, backup	Bez deployu nikt nie używa
Analityka	Event tracking kluczowych akcji	Bez danych nie wiesz, czy działa
Błędy	Czytelny komunikat na każdej ścieżce	Pierwszy bug = utrata zaufania
RODO	Polityka, regulamin, cookie consent	Wymóg prawny, nie opcja

Nic ponad to nie musi być w iteracji 1. Na backlog do iteracji 2 trafia wszystko inne:

• design system,
• testy E2E poza happy path,
• optymalizacja wydajności,
• dark mode,
• i18n,
• infrastruktura testów A/B.

Co NIE robię w MVP — wycinam świadomie

Sześć rzeczy, które każdy spec zawiera, ale których nie zaimplementuję w pierwszej iteracji:

1. Design system

W webowym MVP sięgam po gotowe komponenty (shadcn/ui na webie, NativeBase w React Native). Custom design system ma sens od iteracji 3 wzwyż — gdy już wiadomo, jak produkt wygląda po feedbacku od realnych użytkowników.

2. Testy E2E poza happy path

Zostają dwie rzeczy:

• 3–5 testów E2E na core flow (happy path),
• unit testy na logikę biznesową.

Edge case’y dopisuję, gdy pojawią się w produkcji — nie z wyprzedzeniem. Zysk: wyraźnie szybszy start bez utraty siatki bezpieczeństwa tam, gdzie jest potrzebna.

3. Optymalizacja przed pomiarem

Nie optymalizuję zapytań SQL, nie cache’uję, nie kompresuję obrazków agresywnie. Wszystko ma działać wystarczająco szybko dla pierwszej setki użytkowników. Optymalizacja przed zebraniem realnych danych o wydajności to zgadywanie za pieniądze — najczęściej w miejscu, które nigdy nie było wąskim gardłem.

4. Panele admina

Na starcie panel admina zwykle nie jest potrzebny — wystarczy dostęp do bazy przez narzędzie w rodzaju Retoola albo Supabase Studio. Panel robimy w iteracji 2, gdy pojawią się realne, powtarzalne operacje administracyjne.

5. Wielojęzyczność

i18n konfiguruje się raz, ale tłumaczenia plus utrzymanie dwóch–trzech wersji językowych obciążają każdą późniejszą zmianę treści. MVP po polsku ALBO po angielsku. Drugi język w iteracji 2.

6. Niefunkcjonalne fajne rzeczy

Dark mode, animacje przy hover, czcionki niestandardowe, custom transitions. Wszystko fajne. Wszystko w iteracji 2. Zysk: zwykle kilka dni pracy uwolnionych pod core funkcjonalność.

Matematyka: dlaczego 6 tygodni, a nie 4 ani 10

Sześć tygodni to najmniejszy okres, w którym jednoosobowo da się złożyć MVP z auth, core flow, jedną integracją, deploymentem i minimalną analityką. Mniej = pomijasz coś z must-have’ów (zwykle deploy albo analitykę). Więcej = scope creep.

Tydzień	Co konkretnie
1	Discovery, setup, auth, schema bazy
2–3	Core flow (frontend + backend)
4	Integracja zewnętrzna, płatności
5	Polish, obsługa błędów, edge case’y
6	Deploy, analityka, szkolenie

To ilustracja metody, nie harmonogram z oferty. Terminy podaję orientacyjnie — aplikacje to zwykle ~4–8 tygodni, a dokładny termin po ustaleniu zakresu. Wszystko poza tym pakietem trafia do iteracji 2.

Podsumowanie

MVP w 6 tygodni jest realny pod jednym warunkiem: rozumiesz, że MVP to nie wersja okrojona, tylko najmniejszy produkt dostarczający wartość. Trzy zasady, które trzymam:

1. Jeden flow użytkownika. Nie 3 persony × 5 ekranów.
2. Jedna platforma. Web ALBO mobile ALBO desktop.
3. Jeden integration point. Płatności ALBO SSO ALBO CRM.

Wszystko ponad to — backlog na iterację 2. Tak powstała ta strona i tak wygląda proces, który mogę wycenić fixed-price.

Jeśli masz pomysł i nie wiesz, czy da się go wyciąć do MVP — napisz. Pierwsza rozmowa jest bezpłatna: spisuję zakres i mówię, co wchodzi do pierwszej iteracji, a co do kolejnej.

Aplikacje robię fixed-price od 18 tys. netto (typowo 25–50 tys., + 23% VAT), orientacyjnie ~4–8 tygodni — dokładny termin po ustaleniu zakresu. Odpowiadam do następnego dnia roboczego. Więcej o procesie: aplikacje webowe.