8-Tygodniowa Mapa Drogowa MVP B2B SaaS: Od Pomysłu do Pierwszego Płacącego Klienta

Większość MVP B2B SaaS nie umiera od złego pomysłu, tylko od złego scope'u. Sześć miesięcy później założyciel wciąż dyskutuje o feature flagach, podczas gdy runway się pali, a design partnerzy, których wcześniej zachęcił, dawno poszli dalej. Ten artykuł to ośmiotygodniowy harmonogram, którego używam z finansowanymi klientami na wczesnym etapie, żeby postawić realny, płatny produkt B2B SaaS przed użytkownikami — a nie prototyp, który ktoś wyrzuci.

Wdrożyłem ten konkretny playbook cztery razy od początku 2024 — fintech back-office, vertical SaaS dla zakupów w ochronie zdrowia, spinout narzędzia wewnętrznego. Ograniczenia powtarzają się: budżet pre-seed albo seed, brak własnego zespołu inżynierskiego i shortlista pięciu do dziesięciu design partnerów czekających, aż będą mogli się zalogować. Poniżej harmonogram, stack, cięcia i realny budżet, które sprawiają, że osiem tygodni jest możliwe.

Co tak naprawdę daje ci 8 tygodni

Osiem tygodni wystarcza, żeby przeprowadzić jednego płacącego klienta przez jeden core loop z włączonym billingiem. Nie wystarcza, żeby zbudować platformę, obsłużyć kilka person albo wdrożyć v2 czegokolwiek. Założyciele, którzy traktują harmonogram MVP jak negocjację, zwykle płacą dwa razy — za pospieszny build i za nieuniknioną przebudowę. Potraktuj scope poniżej jak kontrakt, nie listę życzeń.

• —W zakresie: jedna rola użytkownika, jeden core loop, subskrypcja billingowana przez Stripe, mail transakcyjny, podstawowy onboarding, hosting produkcyjny z preview deployami.
• —W zakresie: model jednego tenanta — multi-tenant tylko jeśli twój loop dosłownie wymaga współdzielonych workspace'ów.
• —W zakresie: tyle analytics, żeby odpowiedzieć na pytanie 'czy użytkownik dotarł do value moment' (jeden funnel zdarzeń w PostHogu lub czymś podobnym).
• —Poza zakresem: panel admina poza dashboardem w Retoolu albo Foreście.
• —Poza zakresem: cokolwiek, co wymaga SSO/SAML, granularnego RBAC albo audit logów wykraczających poza domyślne mechanizmy Stripe i providera autoryzacji.
• —Poza zakresem: strona marketingowa wykraczająca poza one-pager — twoi design partnerzy nie przychodzą z SEO w tygodniu dziewiątym.

Tydzień 0: pięciodniowe przygotowanie

Tydzień przed napisaniem pierwszej linijki kodu jest najważniejszym tygodniem projektu. Pomiń go i spędzisz tygodnie trzeci do piątego negocjując scope zamiast budować. Deliverable poniżej to nie specyfikacje — to kontrakty, które pozwalają mi jako kontraktorowi odmówić dorzucania scope'u w środku buildu bez bycia tym złym.

• —Jednoakapitowy problem statement, który nazywa kupującego, trigger event i alternatywę, której teraz używa.
• —Jednozdaniowy opis core loopa ('użytkownik wgrywa CSV, system flaguje anomalie, użytkownik je rozwiązuje, dostaje cotygodniowy digest').
• —Trzy wireframe'y — pusty stan, value moment i ekran billingu. Lo-fi wystarczy. Figma opcjonalnie.
• —Potwierdzona shortlista trzech do pięciu design partnerów, którzy zgodzili się być na pokładzie w tygodniu ósmym.
• —Podpisany kontrakt albo letter of intent, żeby żadna ze stron nie renegocjowała w środku sprintu.

Stack: nudny z premedytacją

Stack poniżej to ten sam, którego używam dla każdego klienta, bo jest przewidywalny, łatwy do hire'owania i wybaczający. Ośmiotygodniowy harmonogram to nie miejsce, żeby przedstawiać inżyniera nowemu frameworkowi. Każdy nowatorski wybór — nowy ORM, nowy edge runtime, nowa biblioteka auth — kosztuje mniej więcej pół tygodnia debugowania, którego nie masz. To wersja domyślnych wyborów na 2026 rok, którą faktycznie wdrożyłem w produkcji.

Tygodnie 1–2: fundament

Pierwsze dwa tygodnie są nieefektowne i decydują, czy tygodnie trzy do osiem będą czuły się jak budowanie, czy gaszenie pożarów. Output to nie feature, który founder może zademonstrować — to działający kręgosłup, na który następne sześć tygodni features się przykręca. Powstrzymaj się od pokazywania widocznego UI wcześnie; zapłacisz za to dwa razy.

• —Flow auth: signup, login, reset hasła, tworzenie organizacji, zaproszenie przez email.
• —Schemat bazy dla kluczowych encji, z migracjami Prismy zacommitowanymi w repo.
• —Szkielet API: moduły NestJS dla dwóch albo trzech zasobów, których dotyka core loop, z DTO i walidacją na miejscu.
• —CI na GitHub Actions: typecheck, lint, build, podstawowy e2e na flow auth.
• —Preview deploye dla każdego PR — founder reviewuje realne URL-e, a nie screenshoty.
• —Sentry, PostHog i webhooki Stripe podłączone, ale uśpione (jeszcze bez produktów).

Tygodnie 3–5: core loop

To jedyna część buildu, której nie da się zastąpić. Trzy tygodnie na jeden workflow, za który płaci klient. Wszystko, co nie leży na ścieżce od 'użytkownik się loguje' do 'użytkownik dociera do value moment', jest przesunięte. Founderzy uważają to za brutalne w tygodniu trzecim i są wdzięczni w tygodniu ósmym.

“Jeśli nie umiesz opisać swojego core loopa w jednym zdaniu, nie jesteś gotowy go budować. Spędź jeszcze tydzień z klientami — to taniej niż przebudowa.”

Tygodnie 6–7: billing, onboarding, wykończenie

Dwa tygodnie, żeby wziąć core loop i opakować go we wszystko, co zamienia oglądającego w płacącego. Stripe Billing to kręgosłup; onboarding i wykończenie to tkanka łączna. Niedoinwestujesz tego i twoi design partnerzy pokochają produkt, ale nigdy nie wpiszą karty.

• —Stripe Billing live z co najmniej dwoma planami i trialem 14-dniowym — bez karty kredytowej przy signupie.
• —Customer Portal embedowany, żeby użytkownicy sami robili upgrade'y i kasowali subskrypcje.
• —Onboarding flow, który prowadzi użytkownika do value moment w mniej niż pięć minut (checklista UI wystarczy).
• —Puste stany dla każdego list view — screenshot przyszłości, a nie biała strona.
• —Stany błędów dla każdego formularza: błędy serwera, problemy sieciowe, komunikaty walidacji z konkretnymi instrukcjami.
• —Maile transakcyjne: powitanie, zaproszenie, reset hasła, paragon billingowy, cotygodniowy digest, jeśli loop tego wymaga.
• —Strony 404 i 500 zgodne z brandem, linkujące z powrotem do aplikacji.
• —Health check pod /healthz, żeby logika restartu twojego providera hostingu faktycznie działała.
• —Lighthouse passuje na one-pagerze marketingowym i na zalogowanym dashboardzie.
• —Nagrany Loomem walkthrough pełnego happy patha, który founder może wysłać design partnerom.

Tydzień 8: soft launch z design partnerami

Tydzień ósmy to nie launch na Product Hunt. To tydzień, w którym design partnerzy ustawieni w tygodniu zerowym się logują, przechodzą przez workflow i są obciążani. Cel to dwa rezultaty: płacący klient i backlog feedbacku, który uzasadnia kolejny sprint. Cokolwiek poza tym — publiczny launch, paid acquisition, content — przychodzi później.

• —Indywidualne calle onboardingowe z każdym design partnerem. Bez masowych maili.
• —Wspólny inbox feedbacku na Slacku albo Linearze, który founder triażuje codziennie.
• —Stripe w trybie live z realną płatnością od co najmniej jednego design partnera przed końcem tygodnia.
• —Prosta strona changelog, żeby partnerzy widzieli fixy wjeżdżające w czasie rzeczywistym.
• —Retrospektywa końca tygodnia z founderem: co zostawiamy, co tniemy, co podkręcamy w tygodniu dziewiątym.

Czego odmawiam budować w 8 tygodni

• —Custom panel admina — używaj Retoola, Foresta albo bezpośredniego SQL-a, dopóki wolumen tego nie uzasadni.
• —Granularny RBAC poza owner/member — twoich pierwszych dziesięciu klientów nie ma macierzy uprawnień.
• —Multi-region deployment — single-region na kontynencie kupującego wystarczy do Series A.
• —Custom dashboard analityczny — PostHog albo Metabase wpięty w Postgresa pokrywa pierwsze 18 miesięcy.
• —Feature flagi jako infrastruktura — branchowanie środowisk plus boolean kolumna na userze prowadzi cię do setki klientów.
• —Aplikacja mobilna — każdy B2B MVP, który wdrożyłem, osiągnął product-market fit najpierw na responsive web app.
• —System white-label albo theming — nie masz jeszcze drugiego brandu.
• —SSO/SAML — wpisz to na stronie cennika jako 'Enterprise — kontakt z sales' i wróć w czwartym miesiącu.

Realny koszt

Uczciwy budżet na ośmiotygodniowe MVP zbudowane przez seniora kontraktora to od trzydziestu pięciu do siedemdziesięciu pięciu tysięcy dolarów all-in. Tańsze zlecenia albo używają juniorskiego zespołu, który przeciąga się o szesnaście tygodni, albo skreślają pracę nad wykończeniem i billingiem, która zamienia demo w biznes. Rozbicie poniżej to to, na co wyceniam i co inni founderzy z US/EU faktycznie płacą w 2026.

Kiedy 8 tygodni nie wystarczy

Osiem tygodni zawodzi przy wąskim zestawie dobrze zdefiniowanych kształtów produktu. Jeśli twój MVP wymaga którejkolwiek z pozycji z listy poniżej, dobry ruch to albo agresywnie skreślić scope, dopóki nie znikną, albo zabudżetować dwanaście do szesnastu tygodni. Udawanie inaczej to dokładnie to, co prowadzi do przebudowy.

• —Branże regulowane wymagające SOC 2, HIPAA albo PCI, zanim podpisze się jakikolwiek płacący klient — dodaj cztery do ośmiu tygodni pracy nad compliance.
• —Hardware w pętli, w tym IoT, point-of-sale albo cokolwiek z zależnościami od firmware'u.
• —Naprawdę ML-driven core, gdzie jakość modelu jest produktem, a nie chrome'em wokół wywołania LLM.
• —Real-time collaboration jako core loop (CRDT, presence, OT) — głębia inżynierska bliższa dwunastu tygodniom skupionej pracy.
• —Founderzy, którzy nie mogą poświęcić czterech godzin tygodniowo na decyzje produktowe i rozmowy z design partnerami. Harmonogram nie przeżyje nieobecnego foundera.

Co się dzieje w tygodniu 9

Tydzień dziewiąty to nie moment na skalowanie infrastruktury albo zatrudnianie zespołu — to moment, żeby spędzić każdą dostępną godzinę z design partnerami, którzy właśnie ci zapłacili. Pierwszy płacący klient to punkt startu, a nie linia mety. Produkt, który wdrożysz w tygodniu ósmym, będzie nie do poznania w tygodniu szesnastym i to jest właściwy rezultat.

Jeśli jesteś wewnątrz tego ośmiotygodniowego okna z pomysłem na B2B SaaS i chcesz kontraktora, który wdrożył dokładnie ten kształt projektu wcześniej — zacznij rozmowę o scopingu. Jeśli jesteś jeszcze przed harmonogramem i ważysz fundamentalne decyzje — stack, hosting, baza danych — powiązany wpis o Postgresie ponad NoSQL i przewodnik po monolicie vs mikroserwisach to naturalne kolejne lektury.

Powiązane Artykuły

PostgreSQLDatabase

Dlaczego Wybrałem PostgreSQL Zamiast NoSQL dla Projektu SaaS