Van idee naar betaalde SaaS
in 6–10 weken.
Vier sprints: foundation (auth, marketing-site, DB-schema), kernproduct (het ene ding waarom je SaaS bestaat), billing & polish (Stripe, trial-flow), onboarding & livegang. Dat is het. Niet "alle features dag 1".
Q1Lukt 6 weken écht?+
Verdieping: waarom solo-MVP's nu zinvol zijn
Het SaaS-MVP-landschap is sinds 2023 fundamenteel verschoven door drie krachten: (a) auth en billing zijn gecommoditiseerd (Supabase, Clerk, Stripe Billing), (b) Postgres + pgvector dekt nu zowel relationele data als AI-embeddings in één database, (c) de infrastructuur is goedkoop geworden. Let op de kleine letters: het Hobby-plan van Vercel is volgens Vercel bedoeld voor persoonlijk, niet-commercieel gebruik, dus een commerciële SaaS hoort op een betaald plan. Dat betaalde plan plus Supabase en Stripe kost tientallen euro's per maand, geen duizenden. Wat in 2020 een team van 3–4 vereiste, doet één ervaren ontwikkelaar in 6–10 weken.
De kern-fout die ik bij founders zie is te veel features in MVP. Een MVP heeft één kernflow, niet vijf. Vijf half-werkende features verkopen niet. Eén gepolijste kernflow met decent onboarding wel. Schrap brutaal — wat overblijft is wat je echt aan klanten gaat tonen.
Stappenplan: vier sprints van idee tot betalend
1Sprint 1 — Foundation (week 1–2)+
2Sprint 2 — Kernproduct (week 3–4)+
3Sprint 3 — Billing & polish (week 5)+
4Sprint 4 — Onboarding & livegang (week 6)+
De productie-stack — gekozen, niet vergaderd
Veelgestelde vragen
Q1Hoeveel klanten moet ik hebben om te starten?+
Q2Wat als ik later een team wil toevoegen?+
Q3Krijg ik de code, of staat alles bij jullie?+
Q4En als ik later AI wil toevoegen?+
Q5Wat is de typische running cost na livegang?+
Lange-termijn perspectief: van MVP naar duurzaam product
Een MVP is geen eindpunt — het is het startpunt van wat doorgaans 18–36 maanden iteratie wordt voordat een SaaS-product duurzaam draait op terugkerende omzet. De architectuurkeuzes die je nu maakt bepalen hoe duur die iteratie wordt. Standaard-stack (Next.js + Postgres + Stripe + Supabase) garandeert dat elke nieuwe ontwikkelaar binnen een week productief is. Proprietary stack (BaaS-lock-in, eigen framework, custom auth-systeem) garandeert dat je over 18 maanden vastzit aan dezelfde uitvoerder of voor pijnlijke migraties staat.
De drie schaal-momenten in een typische SaaS-evolutie: (a) 10–100 actieve users (alles werkt out-of-the-box, focus op product-market-fit), (b) 100–1.000 users (eerste echte schaal-issues: query-performance, e-mail-deliverability, support-volume — meestal op te lossen met indexes, queues en een basale RAG-supportbot), (c) 1.000+ users (multi-region overwegen, dedicated DB-instance, observability-stack).
Wat ik consistent zie: founders investeren in MVP-fase te veel in features en te weinig in onboarding. Drie weken werk in goede onboarding (welkom-mails, in-app walkthrough, slimme empty states) levert vaak meer activatie op dan zes weken werk in feature-uitbreiding. De vraag “wat moeten ze als eerste doen?” is belangrijker dan “wat kan het allemaal?”.
Deze vier sprints in de praktijk: Sessia
De meeste opdrachten vallen onder een geheimhoudingsverklaring, dus die beschrijven we hooguit geanonimiseerd. Sessia mogen we met naam noemen: die klant staat met toestemming op de site en de case is gepubliceerd. De founder kwam in oktober 2025 met een idee voor een sessie-gebaseerd boekingsplatform, acht weken later stond het live. Wij bouwden het platform op Next.js, Supabase met auth en row-level security, Stripe Connect voor de marketplace-billing en Resend voor transactionele mail. Die acht weken waren vier sprints uit onze eigen projectplanning, met aan het eind van elke sprint een demo en daarna één livegang.
Het cijfer dat erbij hoort, met de telwijze erbij: 50 betalende boekingsklanten van het platform, geteld over de eerste acht weken na livegang. Dat is een opgave van de opdrachtgever, geen meting van ons, en op aanvraag te verifiëren. Even belangrijk voor wie deze roadmap naast zijn eigen plan legt: wij leverden merk, platform en betalingen, de acquisitie deed de opdrachtgever zelf. Vier sprints leveren een product op dat kan factureren; wie er dan betaalt, hangt af van wat jij daarna doet.
Wat de planning haalbaar hield, was strikte scope-discipline in week 1. We schreven op één pagina wat erin zat en wat niet, en die pagina werd niet veranderd zonder change request. Wat de founder onderweg bedacht ("kunnen we ook X toevoegen?") schoven we door naar v1.5, die vier weken na livegang inging.
Het verschil tussen "iets bouwen" en "iets bouwen dat werkt" is een paar weken extra discipline op scope, niet meer code. — uit project-retrospectief Sessia, december 2025