Jak zbudować MVP SaaS od zera — architektura, auth, billing w 2026

MVP SaaS to nie prototyp. To ważna różnica, która decyduje o tym, czy produkt przeżyje pierwsze tygodnie po launchu.

Prototyp można zbudować w weekend. Zbiera się dane, weryfikuje hipotezę, wyrzuca. MVP SaaS musi wytrzymać prawdziwych użytkowników, prawdziwe pieniądze i prawdziwe wymagania dotyczące bezpieczeństwa. Jeśli budujesz coś, co chcesz sprzedawać jako produkt — potrzebujesz auth, bazy danych i Stripe od pierwszego dnia. Nie "może później". Nie "jak zrobimy traction". Teraz.

Poniżej opisuję jak do tego podchodzimy w MKM Labs. Opinionated, konkretny, bez "to zależy".

Czym jest MVP SaaS, a czym nie jest

MVP SaaS to minimalny zestaw funkcji, który pozwala prawdziwemu użytkownikowi zapłacić za realną wartość i regularnie wracać. Nie demo. Nie landing page z formularzem "zostaw email". Działający produkt z działającymi płatnościami.

To oznacza, że już na początku musisz mieć: rejestrację i logowanie, izolację danych między użytkownikami lub organizacjami, płatności z obsługą subskrypcji i webhooków, oraz deployment na produkcji z SSL i własną domeną. Reszta to kolejne iteracje.

Firmy, które pomijają te warstwy "żeby szybciej dotrzeć do rynku", płacą za to dwa razy: raz przy launchcie gdy czegoś brakuje, drugi raz gdy trzeba to przebudować pod presją rosnącej bazy użytkowników.

Stack technologiczny w 2026: nasze wybory

Po kilku projektach SaaS wypracowaliśmy zestaw, który pozwala nam dotrzeć do produkcji w 2–4 tygodnie bez kompromisów architektonicznych.

Frontend i routing: Next.js 15 lub Astro 5 w zależności od charakteru produktu. Next.js jeśli aplikacja jest interaktywna i potrzebuje renderowania po stronie serwera z dynamicznym routingiem. Astro jeśli większość stron to content z wyspami interaktywności — generuje minimalne JavaScript, ładuje się błyskawicznie. Oba mają App Router / Content Collections, TypeScript out of the box i doskonałe wsparcie dla edge deployment.

Backend API: Hono na Node.js. Hono to lekki, typowany framework, który działa identycznie na Node, Bun, Cloudflare Workers i Deno. Piszesz raz, deployujesz wszędzie. Przy MVP SaaS to ważne — możesz zacząć na Railway i przenieść na Cloudflare Workers gdy skala tego wymaga, bez przepisywania API.

Baza danych: PostgreSQL z Drizzle ORM. Drizzle generuje schemat TypeScript, który jest spójny z bazą — typy są inferowane automatycznie, migracje są deterministyczne. Nie ma "magic" jak w Prisma, co jest zaletą gdy coś się psuje. PostgreSQL bo jest dojrzały, ma pełne wsparcie dla JSON columns gdy potrzebujesz elastyczności, row-level security dla multi-tenancy i świetny ekosystem managed hostingów.

Auth: nie rób tego sam

Autoryzacja to obszar, gdzie własne rozwiązanie kosztuje za dużo, a błędy kosztują więcej. W 2026 masz dwie dojrzałe opcje, które polecamy bez zastrzeżeń.

Clerk to najbardziej kompletne rozwiązanie — gotowe komponenty UI, obsługa organizacji (multi-tenancy out of the box), SSO, MFA, webhooks o zdarzeniach użytkownika, integracja z Next.js przez middleware. Cena: za darmo do 10 000 użytkowników MAU. To wystarcza na cały etap tractionu. Clerk obsługuje routing sesji, tokeny JWT, refresh logic — nie musisz tego dotykać.

Auth.js (dawniej NextAuth.js) to open-source alternatywa, którą możesz hostować samodzielnie. Więcej kontroli, zero opłat, ale musisz utrzymywać własne tabele sesji i implementować organizacje samodzielnie. Polecamy Auth.js gdy klient ma wymagania compliance, które wykluczają zewnętrznych dostawców sesji.

Czego nie robimy: własny JWT management, własna obsługa refresh tokenów, własne tabele użytkowników pisane od zera. To godziny pracy i tygodnie debugowania edge casów. Biblioteki rozwiązały te problemy lata temu.

Billing: Stripe od dnia pierwszego

Stripe to jedyna opcja przy nowym SaaS w 2026. Nie dlatego, że nie ma alternatyw — są, i niektóre mają niższe prowizje. Ale Stripe ma najlepsze SDK, najlepszą dokumentację i najdojrzalszy system webhooków w branży.

Kluczowa decyzja: Stripe Checkout czy własny formularz płatności. W MVP zawsze zaczynamy od Stripe Checkout — hosted flow od Stripe, gdzie użytkownik wchodzi na stronę Stripe, płaci, wraca. Zero certyfikacji PCI DSS po Twojej stronie, obsługa kart, BLIK, PayPal i 30+ innych metod. Własny formularz dodajemy tylko gdy design systemu tego absolutnie wymaga.

Webhooks to serce integracji Stripe. Każda zmiana subskrypcji (nowa płatność, odnowienie, anulowanie, failed payment) trafia jako event na Twój endpoint. Musisz obsługiwać co najmniej: checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.deleted. Bez tego masz niespójność między stanem w Stripe a stanem w swojej bazie — użytkownicy, którzy anulowali subskrypcję, nadal mają dostęp do premium. To realny problem w produkcji.

Stripe CLI pozwala testować webhooks lokalnie — uruchamiasz stripe listen --forward-to localhost:3000/api/webhooks/stripe i dostajesz eventy z Stripe w czasie rzeczywistym, bez publicznego tunelu.

Multi-tenancy: org-per-row to właściwy start

Multi-tenancy to pytanie o izolację danych między organizacjami lub użytkownikami. Są dwa główne podejścia i oba mają swoje miejsce.

Org-per-row (row-level security) to model, w którym wszystkie organizacje siedzą w tych samych tabelach, a izolacja odbywa się przez kolumnę organization_id i PostgreSQL Row Level Security. Możesz to wdrożyć w jeden dzień, działa bez osobnych deployment, jest łatwe do migracji. To właściwy wybór dla MVP SaaS z nieodróżnialnymi tenant-ami.

Osobne schematy PostgreSQL (schema-per-tenant) to izolacja na poziomie bazy — każda organizacja ma własny schemat z własnymi tabelami. Daje silniejszą separację, łatwiejsze backupy per-tenant i możliwość różnych wersji schematu. Ceną jest złożoność: musisz zarządzać migracjami na setkach schematów, connection pooling jest trudniejszy, a monitoring wymaga więcej pracy.

Dla MVP SaaS: org-per-row z RLS. Gdy produkt urośnie do punktu gdzie enterprise klienci wymagają dedykowanego storage — wtedy migrujesz.

Deployment: Railway dla szybkości, Fly dla skali

W 2026 mamy trzy sensowne opcje dla SaaS MVP.

Railway to nasz domyślny wybór na start. Deployment z GitHuba w kilka minut, automatyczne SSL, managed PostgreSQL, Redis i inne serwisy w jednym miejscu. Cena jest przewidywalna — płacisz za zużyte zasoby, nie za czas. Dla MVP zużywającego mało pamięci to często 10–30 USD miesięcznie. Railway nie wymaga znajomości Kubernetes, Nginx ani konfiguracji sieciowej — deployujesz i działa.

Fly.io daje więcej kontroli przy podobnej prostocie. Możesz wybierać regiony, masz pełny dostęp do VM, możliwe jest deployment na edge. Polecamy gdy latency jest krytyczna (aplikacja real-time) lub gdy klient wymaga danych w konkretnym regionie EU.

VPS (Hetzner, Contabo) to opcja gdy masz doświadczenie devops i chcesz minimalizować koszty przy stałym obciążeniu. Na Hetzner CX21 (za około 60 PLN miesięcznie) możesz hostować małe SaaS z bazą danych — ale musisz sam zarządzać backupami, SSL i aktualizacjami. Polecamy tylko jeśli ktoś w zespole to dobrze zna.

Jak pracujemy w MKM Labs

Nasz typowy projekt SaaS MVP trwa 2–4 tygodnie. W pierwszym tygodniu definiujemy schemat bazy danych, projektujemy flow użytkownika i ustawiamy infrastructure (Railway, PostgreSQL, Clerk lub Auth.js). W drugim tygodniu budujemy core features — dashboard, CRUD na kluczowych encjach, integracja Stripe. W trzecim i czwartym tygodniu zamykamy płatności, onboarding i deployment na produkcji z własną domeną klienta.

Na końcu klient ma działający produkt, który może pokazać użytkownikom i od którego może zacząć pobierać płatności. Nie "prawie gotowy". Nie "potrzebuje jeszcze tygodnia". Gotowy.

Stack jest spójny między projektami, co pozwala nam nie wymyślać koła za każdym razem — ale dostosowujemy go do specyfiki produktu. Jeśli SaaS wymaga real-time (kolaboracja, chat) — dodajemy WebSockety przez Ably lub Liveblocks. Jeśli wymaga zaawansowanego search — Elasticsearch lub Typesense. Rdzeń pozostaje ten sam.

Budujesz SaaS i potrzebujesz partnera technicznego?

Jeśli masz pomysł na SaaS i chcesz dotrzeć do produkcji szybko, bez przepalania budżetu na przebudowy — napisz do nas. Pierwsze spotkanie jest bezpłatne, a zaczynamy od omówienia architektury, nie od cennika. Kontakt przez formularz na mkmlabs.pl lub bezpośrednio na mateusz.pilecki89@gmail.com.

SaaS MVP architektura Stripe
Udostępnij:

Potrzebujesz podobnego rozwiązania?

Porozmawiajmy o Twoim projekcie

Pierwsza rozmowa jest bezpłatna. Opisz nam swój pomysł — odpowiemy w ciągu jednego dnia roboczego.

Umów bezpłatną rozmowę
Wróć do wszystkich artykułów