Ile trwa zbudowanie MVP? Skupione webowe MVP trwa 3 do 5 tygodni, gdy testuje jeden workflow ze standardową auth, jednym modelem danych i jedną metryką sukcesu. Trwa 6 do 12 tygodni lub dłużej, gdy brief obejmuje wiele ról, ciężkie integracje lub akceptację komitetu.
Niewygodna część jest taka, że kalendarz zwykle jest decyzją o scope, a nie faktem inżynierskim.
Jeśli porównują Państwo teraz wyceny, rozpiętość prawdopodobnie myli z dobrego powodu. Jedne zespoły wyceniają pierwszy test, a inne małą wersję produktu docelowego. Ten przewodnik pokazuje harmonogram stosowany w webvise, blokady, które go wydłużają, oraz reguły cięcia, które nie pozwalają MVP udawać pełnego buildu.
- 3 do 5 tygodni jest realistyczne dla jednego workflow. Oznacza to jednego głównego użytkownika, jedno zadanie, jedną strukturę bazy danych, jedną metrykę launchu i szybkie decyzje.
- 6 do 12 tygodni jest normalne, gdy scope ma wiele ról lub głębokie integracje. Oznacza to większe pierwsze wydanie.
- Pierwszy tydzień decyduje o harmonogramie. Wolny dostęp do kont, niejasne reguły akceptacji i późne decyzje API kosztują więcej czasu niż kod.
- webvise definiuje MVP wokół jednego głównego celu uczenia się i może dostarczyć skupione pierwsze wydania w 3 do 5 tygodni na Next.js, PostgreSQL i Vercel, z logowaniem, płatnościami i środowiskiem demo dla inwestorów, gdy ma to znaczenie. Zobacz specyfikację usługi.
- Najbezpieczniejsze MVP to najmniejszy produkt, który może wygenerować decyzję w ciągu 30 dni od launchu.
Krótka odpowiedź według scope
Publiczne przewodniki po harmonogramach MVP zwykle mieszczą się między 4 a 12 tygodniami. Ten zakres nie jest błędny, ale ukrywa użyteczne pytanie: o jakim typie MVP mowa?
W webvise odpowiedź dzieli się według kształtu scope. Obietnica 3 do 5 tygodni dotyczy webowego MVP z jasnym workflow, ustalonym stackiem technicznym i właścicielem decyzji, który może ciąć funkcje w trakcie buildu.
| Kształt scope | Typowy harmonogram | Co to sprawdza |
|---|---|---|
| Klikalny prototyp | 2 do 5 dni | Czy ktoś rozumie ofertę i flow? |
| Test No-code | 1 do 2 tygodni | Czy ludzie klikają, zapisują się lub płacą, zanim istnieje software? |
| Skupione webowe MVP | 3 do 5 tygodni | Czy jeden użytkownik może ukończyć główny workflow na realnych danych? |
| Standardowe MVP produktowe | 6 do 12 tygodni | Czy wiele ról może używać produktu z realnymi integracjami? |
| Regulowane lub marketplace MVP | 12+ tygodni | Czy produkt obsłuży ryzyko, uprawnienia, compliance albo dwustronny popyt? |
Jeśli Państwa pomysł najpierw potrzebuje landing page, listy oczekujących i ręcznej obsługi, nie warto jeszcze płacić za MVP. Jeśli potrzebuje auth, jednego workflow, bazy danych, deploymentu i analytics, pasuje do ścieżki MVP development webvise.
Wersja tydzień po tygodniu
MVP w 3 do 5 tygodni sprawdza się, gdy ryzykowne decyzje zapadają przed kickoffem, a pierwsze wydanie jest wystarczająco wąskie, by szybko je przetestować.
| Faza | Co się dzieje | Potrzebna decyzja |
|---|---|---|
| Przed kickoffem | Cel nauki, użytkownik, workflow, metryka launchu, konta i twarde cięcia są nazwane | Jeden właściciel akceptuje granice scope |
| Tydzień 1 | UX flow, model danych, auth, deployment i pierwsza klikalna ścieżka | Brak nowej roli użytkownika bez usunięcia czegoś innego |
| Tydzień 2 | Główny workflow, zapisy do bazy, ścieżka email lub płatności, podstawowa potrzeba admina | Integracje zostają standardowe, chyba że dowodzą produktu |
| Tydzień 3 | Realne dane, analytics, obsługa błędów, testy mobile, pierwszy test wewnętrzny | Do scope wchodzą tylko defekty i blokery launchu |
| Tydzień 4 | Polish dla użytkownika, copy, handoff, tracking, produkcyjny deploy | Launch wygrywa z kolejną rundą zmian preferencji |
| Tydzień 5 | Bufor na feedback, przypadki płatności, problemy z API partnera lub czyszczenie danych | Wszystko niezwiązane z launchiem przechodzi po wydaniu |
Stack nie jest sztuczką. webvise zwykle buduje ten poziom na Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel i podstawowych analytics. Szybkość wynika z użycia znanych części oraz odmowy wymyślania infrastruktury, zanim produkt ma dowody.
Co zmienia 3 tygodnie w 3 miesiące
Większość opóźnień MVP nie wynika z trudnej inżynierii. Wynika z decyzji, które zostały miękkie, bo nikt nie chciał ciąć pracy miłej, ale niekoniecznej.
| Źródło opóźnienia | Jak to brzmi | Jak utrzymać harmonogram |
|---|---|---|
| Role użytkowników | 'Admin, kupujący, sprzedawca, partner i support potrzebują dashboardów' | Wybrać jednego głównego użytkownika i jednego operatora wewnętrznego |
| Integracje | 'Potrzebujemy CRM, billing, analytics, Slack i starej bazy danych w dniu pierwszym' | Zostawić tylko system potrzebny do udowodnienia workflow |
| Pętle akceptacji | 'Zespół sprawdzi, gdy wszyscy będą mieli czas' | Nazwać właściciela cięć z czasem odpowiedzi 24 godziny |
| Scope designu | 'Dokończmy wszystkie ekrany w Figma, zanim zaczniemy budować' | Zaprojektować najpierw ścieżkę główną i dopracować po tym, jak działa |
| Roszczenia compliance | 'Może później będziemy potrzebować audit logs' | Zbudować tylko kontrole prawne i bezpieczeństwa potrzebne pierwszym użytkownikom |
Dlatego krótki brief MVP ma większe znaczenie niż długa lista funkcji. Szablon w przewodniku po MVP requirements document to wersja, którą chcę zobaczyć przed buildem o stałej cenie.
Minihistoria: zakres był właściwy z dobrego powodu
W jednym MVP nieruchomościowym termin nie był arbitralny. Obietnica biznesowa była konkretna: kupujący miał otrzymać wiążący certyfikat finansowania bez zapytania do biura kredytowego, podczas gdy system porównywał opcje banków partnerskich w tle. Taki produkt może powstać szybko, gdy pierwsza wersja chroni jeden workflow zamiast próbować stać się pełną platformą finansową.
To nie było małe MVP i nazywanie go tak byłoby nieuczciwe. Pierwsza wersja potrzebowała kompletnego workflow finansowania, automatycznego generowania certyfikatów PDF i dashboardu administracyjnego do cyklu życia wniosku.
Rezultat nadal pozostał lean: skupiony build, mocny wynik Lighthouse, szybkie strony i realizacja certyfikatów w obiecanym oknie obsługi. Harmonogram wydłużył się, bo workflow miał prawdziwe dane finansowe i realne przekazanie operacyjne, a nie dlatego, że zespół dodawał ozdobne funkcje.
Minihistoria: vibe-coded MVPs oszczędzają dni, a potem tracą tygodnie
Dnia 2026-05-18 pisałem o MVPs z Lovable, Bolt i v0. Te narzędzia są przydatne do prototypów, ponieważ pokazują pomysł foundera w ciągu godzin. Problem zaczyna się, gdy prototyp jest traktowany jako fundament produktu.
Ten wzorzec jest na tyle stały, że zapisałem regułę: gdy vibe-coded app ma realnych użytkowników, przebudowuję ją zamiast łatać. Czysty build na moim stacku zwykle trwa 3 do 6 tygodni. Ratowanie może zająć 8 do 12 tygodni, ponieważ każda poprawka musi respektować schemat, strukturę routingu i żywy model danych, którego nikt nie zaprojektował.
To mniej efektowna odpowiedź, ale lepsza dla budżetu. AI app builders warto używać do nauki, co produkt powinien robić. Build MVP jest właściwy, gdy następną potrzebą są wiarygodne dane od realnych użytkowników.
Test harmonogramu w 30 minut
Zanim poproszą Państwo agencję o harmonogram, warto przepuścić scope przez ten test. Jeśli nie da się odpowiedzieć w 30 minut, projekt nie jest jeszcze gotowy na stały kalendarz.
- Jedno zdanie: jaką ryzykowną hipotezę ma udowodnić wersja pierwsza?
- Jeden użytkownik: kto używa pierwszego wydania przed wszystkimi innymi?
- Jeden workflow: jakie kroki prowadzą tego użytkownika od wejścia do wartości?
- Jedna metryka: jaka liczba powie w 30 dni, czy kontynuować?
- Jeden właściciel: kto może ciąć lub akceptować scope w ciągu 24 godzin?
- Znane konta: które konta auth, payment, email, analytics, hosting i database są gotowe?
- Twarde cięcia: co nie zostanie wydane przed launchem, nawet jeśli ktoś o to poprosi?
Jeśli odpowiedzi mieszczą się na jednej stronie, MVP w 3 do 5 tygodni może być realistyczne. Jeśli odpowiedzi wymagają workshopu, należy zacząć od briefu. Kosztowa wersja tej samej decyzji jest w przewodniku po kosztach MVP development.
Kiedy dłuższe MVP jest uczciwą odpowiedzią
Niektórych pierwszych wersji nie należy wciskać w 5 tygodni. Dane regulowane, twierdzenia medyczne, decyzje finansowe, marketplace, mobilne app stores i złożone API partnerów mogą uzasadniać dłuższy build.
Test jest prosty: czy dodatkowy czas chroni realnego użytkownika, realną transakcję albo realny obowiązek prawny? Jeśli tak, należy go zachować. Jeśli dodatkowy czas tylko sprawia, że produkt wydaje się pełniejszy, należy go uciąć.
webvise pomaga founderom podjąć tę decyzję, zanim zacznie się kod. Jeśli Państwa MVP powinno być wystarczająco wąskie na 3 do 5 tygodni, usługa MVP development jest właściwą ścieżką. Jeśli to już platforma produkcyjna, usłyszą to Państwo wprost, a scope zostanie określony inaczej.
Dobry harmonogram MVP nie jest pozerstwem. Jest konsekwencją jasnego scope, szybkich decyzji i pierwszej wersji, która ma odpowiedzieć na jedno pytanie biznesowe. Jeśli chcą Państwo, aby webvise sprawdziło brief przed budową, proszę go przesłać.