[Spis treści]Pokaż spis treści
MVP w 8 tygodni jest realistyczne wtedy i tylko wtedy, gdy spełnione są trzy warunki: problem biznesowy jest jednoznacznie zdefiniowany, istnieją realni użytkownicy gotowi testować produkt w tygodniu 4, a zakres da się sprowadzić do jednego głównego flow. DailyHair spełniał wszystkie: (1) event managerowie tracili 6h/tyg na koordynację 30+ patronów medialnych, (2) trzy pilotażowe konferencje czekały na tyg 4-7, (3) jeden flow — zatwierdzenie briefu przez magic link. Poza tymi warunkami „MVP w 8 tygodni” to marketing, nie inżynieria. Płaci się za niego długiem technologicznym, którego nikt nie amortyzuje w bilansie, ale który odkrywa się w miesiącu trzecim po starcie.
Ten tekst stoi na dwóch perspektywach jednocześnie. Po pierwsze — sami uruchomiliśmy 12 własnych produktów jako venture builder i wiemy, co mieści się w 8 tygodniach z własnych pieniędzy. Po drugie — w projektach dedykowanych dla klientów też dostarczamy MVP i wiemy, co mieści się tam, gdzie scope opłaca klient. Te dwa światy uczą różnych rzeczy. Poniższy framework jest ich złożeniem.
Kiedy 8 tygodni jest realistyczne
Vague brief: „Zbudujcie platformę eventową”. Realny: „Partner medialny zatwierdza brief w 3 dni, event za 2 tygodnie”. Jedno to feature list, drugie to bottleneck z zegarem. Problem sformułowany na poziomie konkretnego bólu, konkretnej osoby i konkretnej metryki, którą chcemy zmienić. Jeśli zespół nie potrafi powiedzieć, co przestanie boleć po wdrożeniu MVP — to nie jest MVP, tylko prototyp bez odbiorcy.
Drugi warunek: dostęp do realnych użytkowników w tygodniu 4. Nie hipotetycznych person z warsztatów UX, tylko konkretnych ludzi z imionami i numerami telefonów, którzy zgodzili się testować wcześnie. MVP bez użytkowników w połowie projektu jest testem własnych założeń zespołu, nie rynku. W projektach, w których klient przychodzi ze słowami „użytkowników znajdziemy po premierze”, czas realizacji przesuwa się do 12-16 tygodni — bo i tak będziemy musieli zbudować drugą wersję, zanim pierwsza komukolwiek dostarczy wartość.
Trzeci warunek: pojedynczy primary flow. Użytkownik wchodzi, robi jedną rzecz, wychodzi z wartością. Reszta to garnish — widoki administracyjne, ustawienia, eksport, notyfikacje. Jeśli w MVP są dwa równorzędne flow (np. „dla event managerów i dla mediów patronackich jednocześnie”) — to nie jest MVP, to dwa MVP udające jeden. W 8 tygodniach da się zbudować jeden flow bardzo dobrze albo dwa flow przeciętnie. Przeciętność w MVP jest gorsza od braku MVP, bo podważa hipotezę zamiast jej testować.
Kiedy 8 tygodni czerwona flaga
Klient chciał SAP integration w MVP. Powiedziałem nie. Znalazł innego, który powiedział tak. 16 tygodni później dzwonili do nas. Okno rynkowe zamknęło się. Każda integracja enterprise — SAP PI, Salesforce, NetSuite, ERP na Comarch XL, HL7/FHIR w medycynie, SWIFT w bankowości — to osobny projekt, nie zadanie w sprincie. Sama integracja z SAP-em (uzgodnienia z działem IT klienta, środowiska testowe, mappings) zajmie 6-10 tygodni bez linijki kodu aplikacji. Jeżeli MVP stoi i upada na jednej integracji enterprise, to nie jest MVP — to projekt integracyjny z UI dorzuconym gratis.
MVP dla 50 person w 3 wertykałach w 3 krajach jednocześnie. To waterfall udający agile. Cofnęliśmy do jednego wertykału. W briefie pojawia się „platforma ma obsłużyć zarówno meetupy do 100 osób, kameralne konferencje branżowe, jak i festiwale kulturalne na 50 tysięcy uczestników, z myślą o ekspansji na rynki niemiecki, ukraiński i hiszpański”. Każdy z tych segmentów ma inny model patronatu, inne procesy, inne wymagania regulacyjne. MVP dla wszystkich segmentów oznacza architekturę, która nikomu nie pasuje. Właściwa decyzja: jeden segment w MVP, pozostałe jako v2. Architektura biznesowa MVP powinna być zaprojektowana pod rozszerzalność, ale nie pod wszystkie przypadki naraz.
Trzeci anty-wzorzec: brak mechanizmu testowania na użytkownikach. „Zrobimy testy po wdrożeniu” to nie plan testów — to rezygnacja z testowania. Bez pętli feedback w 4. tygodniu MVP zamienia się w ośmiotygodniowy prototyp, który dopiero po wdrożeniu zaczyna się uczyć. To najkosztowniejszy moment na odkrycie, że problem był źle postawiony — bo budżet jest już wydany.
Czwarty anty-wzorzec: domeny compliance-heavy z audytowalnym workflow. Bankowość (KNF, PSD2, SOX), medycyna (HIPAA, RODO w szczegółach klinicznych), sektor publiczny (EZD RP, PUW, KRI), farmaceutyka (GxP). W tych domenach sama warstwa audytu, retencji danych i uprawnień to 4-6 tygodni pracy. MVP w 8 tygodniach w compliance-heavy domain oznacza albo pominięcie compliance (nieakceptowalne ryzyko), albo skrócenie części produktowej do atrapy. Realny czas MVP w takich domenach: 14-20 tygodni.
DoMoreSoft MVP Scoping Framework
Ta matryca powstała z obserwacji projektów. Wynik poniżej 15? Coś się złamie. 15-20? Ciasno, ale wykonalne. 20+? Zielone światło. Oceniamy projekt w pięciu wymiarach, skala 1-5. Framework jest pragmatyczny — nie zastępuje warsztatu scopingowego, ale ustawia poziom rozmowy w pierwszych 30 minutach.
MVP Scope Checklist — co mieści się w 8 tygodni
Konkretny zakres, który dostarczamy w pragmatycznym MVP przy wyniku framework 20+:
- Autentykacja i rejestracja użytkowników (email/hasło + ewentualnie SSO)
- Jeden primary flow end-to-end — od wejścia do wartości (np. rezerwacja, zamówienie, wypełnienie wniosku)
- Jeden widok administracyjny z podstawowym CRUD-em najważniejszych encji
- Jedna integracja zewnętrzna (płatność, SMS, mapa, email transakcyjny — wybór zależy od domeny)
- Podstawowa analityka produktowa — kto, kiedy, co zrobił, gdzie zerwał
- Deployment na środowisko staging + produkcja, CI/CD, monitoring błędów (Sentry/GlitchTip)
- RODO w minimalnym zakresie: polityka prywatności, eksport i usunięcie konta, zgody
- Dokumentacja techniczna pozwalająca drugiemu zespołowi przejąć kod bez rescue mission
Nie dlatego, że jesteśmy mili. Cokolwiek poza tą listą ma ogon ukrytej złożoności. Multi-tenant? Trzy tygodnie długu architektonicznego. Tryb offline? Osobny projekt. Pełne RBAC? V3, nie v2. Jeśli któryś z powyższych punktów wypada ze scope’u, żeby zdążyć w 8 tygodniach, przestaje to być MVP i staje się prototypem. Fundament, na którym da się budować przez 18-24 miesiące bez przepisywania od zera, ma swoje minimum — i ono jest powyżej.
Co nie mieści się (i dlaczego to nie jest porażka)
- Multi-tenant z pełną izolacją danych. W MVP wystarczy pojedynczy tenant lub shared database z kluczem tenant_id. Pełna izolacja (schema per tenant, database per tenant) to praca architektoniczna na 3-5 tygodni, sensowna dopiero przy pierwszych klientach enterprise.
- Tryb offline i synchronizacja. Aplikacja działająca offline (PWA z offline queue, CRDT, conflict resolution) to osobny projekt. W MVP akceptujemy wymóg stałego połączenia.
- Zaawansowane role i uprawnienia. W MVP wystarczą 2-3 role (user, admin, ewentualnie manager). RBAC z macierzą uprawnień na poziomie pól, ABAC, audit trail każdej zmiany — to v2 lub v3.
- Dashboardy raportowe i BI. Eksport CSV i 3-5 kluczowych wskaźników wystarczą. Pełne raportowanie z filtrowaniem, cohortami i custom queries buduje się dopiero, gdy wiadomo, których danych faktycznie używa zespół biznesowy.
- Internacjonalizacja (i18n). Jeden język w MVP. Dodanie drugiego to minimum 2 tygodnie pracy (ekstrakcja stringów, pluralizacja, daty, waluty, testy) — nie warto płacić za to w MVP, jeśli nie ma jeszcze użytkowników z drugiego rynku.
Odłożenie tych pozycji na v2 to pragmatyczna architektura biznesowa, która nie płaci za funkcjonalność, której jeszcze nikt nie potrzebuje. Każda z nich wróci we właściwym momencie, kiedy będzie uzasadniona konkretną potrzebą, a nie przypuszczeniem. Decyzja, co przesunąć do v2, jest częścią discovery procesu — nie improwizacją na sprincie.
Jak znamy te 8 tygodni — robimy to sami
Zbudowaliśmy MVP DailyHair — platformy do zarządzania patronatami medialnymi i komunikacją wokół wydarzeń branżowych — w 8 tygodniach. Konkret z naszego logu:
- Tyg 1: byliśmy 40% gotowi i spanikowani. Backlog nieproporcjonalny do dni roboczych.
- Tyg 3: wycięliśmy 30% planowanych ficzerów. Multi-channel notyfikacje, custom raporty, integracja z dwoma CRM-ami — wszystko poszło do v2.
- Tyg 6: pierwsza konferencja na produkcji, pivot dwóch flowów po feedbacku event managerów. Magic link wygrał z hasłem.
- Tyg 8: shipped. Trzy pilotaże podpięte, primary flow stabilny.
To nie jest anegdota o tym, jacy jesteśmy sprytni. Dowód, że framework działa wtedy, gdy się go stosuje rygorystycznie — na sobie i na klientach. Robimy to samo od 2016 roku, już na 12 własnych produktach, i każdy z nich uczył nas, co z listy „nice to have” jest naprawdę nice, a co ukrytym długiem technologicznym.
Cost math: 8 tygodni vs. 16 tygodni
Policzmy TCO dwóch ścieżek dla tego samego produktu:
| Pozycja | MVP 8 tyg. | MVP 16 tyg. |
|---|---|---|
| Budżet developmentu | 30-50 tys. EUR | 80-140 tys. EUR |
| Czas do feedbacku rynku | 8 tyg. | 16 tyg. |
| Koszt jednego cyklu nauki | niski | wysoki |
| Ryzyko zbudowania złej rzeczy | ograniczone scope’em | duże (więcej założeń, więcej błędów) |
| Dług technologiczny | kontrolowany przy 20+ w frameworku | niski, jeśli zespół nie spieszył się na siłę |
Matematyka wygląda jednoznacznie, ale jest jeden warunek, który ją odwraca. Zły MVP w 8 tygodniach jest droższy od dobrego MVP w 12 tygodniach. Koszt zbudowania złej rzeczy to nie tylko budżet projektu, ale też koszt alternatywny (czas zespołu), koszt wiarygodności (pierwsi użytkownicy testujący zły produkt więcej nie wracają) i koszt refaktoru pod v2, która wreszcie odpowiada na realny problem. Suma tych kosztów potrafi przekroczyć budżet 16-tygodniowego MVP. Tylko że jest rozproszona w czasie i mniej widoczna w raporcie.
Szybko to nie cel. Cel to wcześnie zweryfikowane założenia. 8 tygodni ma sens wtedy, gdy skraca czas do nauki, a nie gdy skraca czas do „mamy coś, co wygląda jak produkt”.
Red flags od strony klienta, nie tylko dostawcy
Większość artykułów o MVP koncentruje się na tym, co dostawca powinien zrobić dobrze. W praktyce projekty wykolejają się również z powodów po stronie klienta — i uczciwość wymaga nazwania ich wprost. Trzy, które kończą 8-tygodniowy MVP w 16 tygodniach, niezależnie od kompetencji zespołu:
Pierwszy: zmiana zakresu w każdym sprincie. Klient, który co dwa tygodnie dorzuca nowe funkcjonalności („to drobiazg, dodajcie to przy okazji”), gwarantuje poślizg. Każda zmiana zakresu to decyzja, czy wypadamy z 8 tygodni, czy coś innego wylatuje ze scope’u. Nie da się zjeść ciastka i mieć ciastka. Dojrzały klient rozumie, że scope freeze po tygodniu 2 jest warunkiem dostarczenia w terminie.
Drugi: brak dostępu do end-userów. Klient, który mówi „użytkowników wam zapewnimy”, ale po tygodniu 3 wciąż nie ma umówionego pierwszego testu pilotażowego, właśnie wyłączył pętlę uczenia się z produktu. Od tygodnia 4 zespół koduje na oślep — nawet jeśli architektura jest poprawna, decyzje produktowe są zgadywaniem. Moment, w którym warto zatrzymać projekt i zrobić reset.
Trzeci: decision-maker poza projektem. Klient deleguje MVP do menedżera średniego szczebla, który nie ma prawa decydować o scope’u. Każda znacząca decyzja trafia na biurko prezesa, który odpowiada raz na tydzień — najczęściej zmianą scope’u. Warunek współpracy w 8-tygodniowym MVP: decision-maker z decyzyjnością dostępny w cyklu 48-godzinnym.
Chcesz sprawdzić, czy Twój MVP mieści się w 8 tygodniach?
Użyj framework’u powyżej — oceń pięć wymiarów w skali 1-5, zsumuj i zobacz, w której kategorii jesteś. Wynik 20+ — zaczynaj, warunki są spełnione. 15-19 — rozmawiajmy o 10-12 tygodniach albo o przycięciu scope’u. Poniżej 15 — potrzebny jest warsztat discovery, nie MVP.
Napisz na office@domoresoft.com z wynikiem swojej samooceny. Jeśli jesteś na granicy (17-20 pkt), 30-minutowa rozmowa z architektem pokaże, co zostawić w MVP, a co wyciąć do v2 — i ile to naprawdę będzie kosztowało. Dla pogłębienia kontekstu, jak ocenić partnera technologicznego, który ma ten MVP faktycznie dostarczyć, polecamy framework wyboru software house’u w 2026. Nie sprzedajemy „MVP w 8 tygodni” jako produktu z półki — sprzedajemy uczciwą rozmowę o tym, czy te 8 tygodni jest w Twoim przypadku realistyczne.