MVP w 4 tygodnie: co realnie zdążysz zbudować (i ile trwa budowa)

Budujesz produkt i słyszysz dwie skrajne odpowiedzi: jedni obiecują działającą aplikację „w dwa tygodnie”, inni wyceniają pół roku, zanim w ogóle zobaczysz pierwszy ekran. Dla większości projektów prawda leży pomiędzy — sensowny MVP powstaje w 4–8 tygodni. Poniżej rozpisuję, co realnie zmieścisz w tym czasie, co świadomie zostawiasz na później i jak wygląda taki sprint tydzień po tygodniu. Bez obiecywania cudów — to opis tego, co faktycznie wdrażamy, a nie marketingowa obietnica.

Co realnie wchodzi w MVP w 4–8 tygodni

MVP to nie „okrojona apka”. To najmniejsza wersja produktu, która domyka jedną pętlę wartości: użytkownik wchodzi, robi to, po co przyszedł, a Ty masz z tego dane albo pieniądze. Na stacku Next.js + TypeScript + PostgreSQL w 4–8 tygodni realnie zmieścisz:

• Logowanie i konta (auth). Rejestracja, logowanie, reset hasła, sesje. Sprawdzony mechanizm, nie wynalazek pisany od zera.
• Płatności. Stripe albo Przelewy24: jednorazowa płatność lub subskrypcja, webhooki, podstawowe statusy zamówień. Pieniądze realnie wpływają.
• Panel administracyjny. Miejsce, w którym Ty albo Twój zespół zarządzacie treścią, użytkownikami i zamówieniami — bez grzebania ręcznie w bazie.
• Własny backend i baza. Twoje API i model danych w PostgreSQL, dopasowane do Twojej logiki biznesowej, a nie do gotowego szablonu, który za miesiąc Cię uwiera.
• 1–2 integracje AI. Generowanie treści, klasyfikacja, podsumowania albo chat na Twoich danych. Jedna, góra dwie — w krytycznej ścieżce, z fallbackiem i limitem kosztów, a nie demo, które sypie się przy pierwszym nietypowym wejściu.
• Podstawowy panel użytkownika. Profil, historia, ustawienia — to, czego user potrzebuje, żeby wrócić następnego dnia.

To komplet, na którym da się uruchomić produkt i zacząć go sprzedawać lub testować na realnych ludziach. Reszta to już rozbudowa, nie fundament. Kolejność też nie jest przypadkowa: najpierw stawiamy szkielet (auth, baza, główny przepływ), a płatności, AI i integracje dokładamy dopiero wtedy, gdy jest do czego je podpiąć. Dzięki temu już w połowie sprintu klikasz po działającym produkcie, a nie oglądasz statyczne makiety. Jeśli chcesz zobaczyć ten zakres opisany jako konkretną usługę, mamy go rozpisanego na stronie budowy MVP.

Czego nie zdążysz — i czemu to dobrze

Skoro coś wchodzi, to coś musi odpaść. Na start świadomie zostawiamy za burtą:

• Rozbudowane role i uprawnienia. Jeden, góra dwa typy użytkownika wystarczą do walidacji. Macierz „kto co widzi i może zmienić” to robota na tygodnie, nie hipoteza do sprawdzenia.
• Wielojęzyczność. Jeden język, jeden rynek. i18n dokładasz, gdy wiesz, że drugi rynek w ogóle ma sens — nie na zapas.
• Zaawansowane raporty i dashboardy. Na starcie liczy się kilka kluczowych liczb, a nie konfigurowalne wykresy z eksportem do pięciu formatów.
• Natywna apka mobilna. Responsywny web (albo PWA) pokrywa większość potrzeb MVP. Osobny build na iOS i Androida to drugi projekt, nie „przy okazji”.
• Edge case’y. Co się stanie przy 47. kroku nietypowego scenariusza? Na razie nic — bo nikt jeszcze nie zrobił nawet kroku pierwszego.

To nie jest pójście na skróty. MVP istnieje po to, żeby sprawdzić jedną hipotezę: czy ludzie tego chcą i czy zapłacą. Każda funkcja, która nie pomaga odpowiedzieć na to pytanie, to przepalony tydzień i opóźniony moment, w którym poznajesz prawdę. v2 budujesz na danych od użytkowników — nie na swoich domysłach sprzed launchu. Dlatego cięcie zakresu na starcie to nie kompromis jakościowy, tylko najtańszy sposób, żeby szybciej się czegoś nauczyć.

Tydzień po tygodniu

Sprint MVP nie jest czarną skrzynką, do której wrzucasz pieniądze i czekasz na efekt. Pracujemy w cyklach tygodniowych, a kod ląduje w Twoim repozytorium Git od pierwszego dnia — nie na końcu, „jak faktura będzie opłacona”. Tak wygląda typowy bieg na około 6 tygodni:

Co tydzień dostajesz demo na żywo i krótkie review: pokazujemy, co działa, a Ty mówisz, co poprawić albo czemu zmienić priorytet. Ten rytm robi dwie rzeczy. Po pierwsze, nie ma niespodzianki na końcu — kierunek korygujemy w trakcie, a nie po fakcie, kiedy przerobienie czegoś kosztuje już dziesięć razy więcej. Po drugie, to Ty trzymasz rękę na zakresie: jeśli w 3. tygodniu okaże się, że realnie potrzebujesz innej funkcji niż zakładałeś, przesuwamy priorytet, zamiast dowozić plan, który zdążył się zdezaktualizować. Krótszy zakres zamyka się w 4 tygodnie, bardziej złożony rozciąga do 8 — zależnie od liczby integracji i zawiłości logiki — ale schemat pozostaje ten sam: tydzień pracy, demo, decyzja.

Czemu „6 miesięcy na MVP” to red flag

Jeśli ktoś wycenia MVP na pół roku, dzieje się zwykle jedno z trzech. Albo to nie jest MVP, tylko od razu pełny produkt z v2 wciśniętą w zakres. Albo zakres nie został domknięty i „6 miesięcy” to bufor na chaos, który ktoś dyskretnie przerzuca na Ciebie. Albo zespół buduje na zapas — mikroserwisy, skalowanie na milion userów i pięć integracji, których jeszcze nikt nie potrzebuje.

Dla Ciebie jako foundera każdy z tych scenariuszy jest drogi. Pół roku to pół roku spalonego runway’u, zanim w ogóle dowiesz się, czy pomysł chwyta. MVP ma odpowiedzieć na to pytanie szybko i tanio — jeśli odpowiedź brzmi „nie”, chcesz ją usłyszeć po sześciu tygodniach, a nie po sześciu miesiącach i wydanych setkach tysięcy. Im dłuższy pierwszy cykl, tym później uczysz się czegokolwiek o rynku. A na wczesnym etapie tempo nauki jest jedyną przewagą, jaką realnie masz.

Ile to kosztuje

Konkretnie: MVP zaczyna się u nas od 18 000 zł netto i powstaje w 4–8 tygodni. Cenę ustalamy jako fixed price po scopingu — najpierw domykamy zakres, a potem podajemy stałą kwotę i termin, a nie widełki „od do” z dopłatami pojawiającymi się w trakcie.

Jeśli pomysł nie jest jeszcze doprecyzowany — masz kierunek, ale przed Tobą sterta decyzji produktowych — zaczynamy od Discovery Sprintu od 3 000 zł. Wychodzisz z niego z rozpisanym zakresem, architekturą i realną wyceną MVP. To najtańszy moment, żeby wyłapać, że połowa wymarzonych funkcji nie jest potrzebna do walidacji. Pełne rozbicie znajdziesz na stronie z cennikiem, a jeśli chcesz zobaczyć, jak taki zakres wygląda na realnym projekcie, opisaliśmy wdrożenie systemu produkcji od zera w 8 tygodni.

Co dalej po MVP

MVP to początek, nie koniec. Po launchu masz trzy drogi:

1. v2 na danych. Zbierasz feedback i metryki, wracamy do kolejnego sprintu i budujemy to, czego ludzie realnie używają — role, raporty, kolejne integracje. Teraz to ma sens, bo wiesz, co rozwijać.
2. Retainer. Jeśli produkt żyje i wymaga bieżącej opieki, wchodzimy w model Ship & Support od 2 500 zł/miesiąc — poprawki, drobne zmiany, monitoring i rozwój małymi krokami.
3. Czysty handover. Masz własny zespół albo dewelopera? Przekazujemy kod, dokumentację i dostępy. Kod jest Twój od pierwszego dnia, więc handover to formalność, a nie negocjacje o vendor lock-in.

Żadna z tych dróg nie jest narzucona z góry. Wybierasz tę, która pasuje do tego, gdzie jest produkt i Twój zespół.

Zacznij od konkretu

Masz pomysł i chcesz wiedzieć, co z niego realnie zmieścisz w pierwszych 4–8 tygodniach? Umów scoping — wyjdziesz z konkretnym zakresem, stałą ceną i terminem, a nie kolejnym „to zależy”. Zajrzyj do cennika i napisz, co budujesz. Resztę rozpiszemy razem, w liczbach.