Freemium · trial · betaald:
welk model past?
Freemium: virale producten met netwerk-effecten. Trial (14 dagen): SaaS waar waarde < 1 sessie zichtbaar wordt. Pay-from-day-one: hoge intent, B2B, prijs €100+/mnd. De fout: freemium kiezen omdat het "beter klinkt" terwijl je geen viral mechanisme hebt.
Q1Trial-conversie benchmark?+
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) deployment is feitelijk gratis tot betekenisvolle schaal (Vercel hobby + Supabase free + Stripe). 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 kerflow, niet vijf. Vijf half-werkende features verkopen niet. Eén gepolijste kerflow 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 — Kerproduct (week 3–4)+
3Sprint 3 — Billing & polish (week 5–6)+
4Sprint 4 — Onboarding & livegang (week 7–8)+
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. Propietary 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?”.
Concreet voorbeeld uit een lopend project
Een NL-founder kwam in oktober 2025 met een idee voor een sessie-gebaseerd boekingsplatform. Acht weken later: live, eerste 50 betalende klanten, €4k MRR. Stack: Next.js, Supabase Auth + RLS, Stripe Connect voor marketplace-billing, Resend voor transactional. Vier sprints, vier demo's, één livegang. Bouwbudget: €18k. Running cost: €60/mnd in eerste 90 dagen.
Wat het project liet werken: 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. Drie suggesties van de founder onderweg ("kunnen we ook X toevoegen?") werden vriendelijk doorgeschoven naar v1.5. Resultaat: zonder feature-creep haalden we de 8-weken-deadline; v1.5 ging vier weken na livegang in.
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