Boekingsplatform voor prenatale lessen: van MVP naar platformonderdeel
De uitdaging
Een Britse thuiszorgorganisatie waarvoor CleverTech AI al het B2B-platform bouwt, wilde een tweede product starten: een boekingsplatform voor prenatale lessen en geboortelessen in het zuiden van Engeland. Een greenfield product met een compleet andere doelgroep — aanstaande ouders in plaats van zorgprofessionals en zorgverzekeraars — en met kraamzorgdiensten als beoogde tweede fase.
De vraag was in de kern die van elke startup die een app laat maken: hoeveel fundament bouw je vooraf, en hoeveel bewaar je bewust voor later?
Vier dingen maakten dat een lastige afweging:
- Geen enkel bestaand fundament. Het product startte in mei 2026 volledig vanaf nul: geen database, geen authenticatie, geen deploy-pijplijn. Alles wat het B2B-platform van de moederorganisatie al had, moest hier opnieuw of alsnog geregeld worden — maar dan op de schaal van een productlancering, niet op die van een volwaardig platformtraject.
- Besluitvorming vroeg om klikbare schermen. De scopekeuzes — welke flows in de launch moesten en welke konden wachten — lieten zich niet op een specificatie maken. Elf schermen en vier user flows moesten zichtbaar en doorklikbaar zijn voordat daar zinnig over te beslissen viel.
- De toolkeuze zat een kostenrisico in. De eerste route liep via FlutterFlow AI. Dat platform rekent per bericht af, en juist bij intensieve iteratie met stakeholders — tientallen kleine wijzigingen per sessie — loopt die metering hard op. Precies het gedrag dat je in een prototype-fase wilt aanmoedigen, werd daar het duurst.
- Twee sporen in één organisatie. Het product moest zelfstandig kunnen starten en tegelijk niet doodlopen: als het aansloeg, zou het onder hetzelfde dak verder moeten kunnen als de bestaande B2B/zorg-kant, zonder dat alles opnieuw gebouwd wordt.
Kort gezegd: een MVP laten bouwen die snel genoeg klaar is om te lanceren, goedkoop genoeg om verantwoord te zijn als het product niet aanslaat, en solide genoeg om later op te gaan in een groter platform.
De aanpak en oplossing
CleverTech AI bouwde het product als zelfstandig MVP met een volwassen fundament: klein in functionaliteit, niet klein in techniek. Het werk liep langs vier stappen.
1. Het boekingssysteem: een API in Fastify en PostgreSQL
De kern werd een Node/Fastify-API met PostgreSQL eronder, met schema-migraties via node-pg-migrate — zodat elke databasewijziging vanaf commit één versiebeheerd en herhaalbaar is.
Authenticatie loopt via Firebase, maar de API vertrouwt niet blind op de tokens: JWT-verificatie gebeurt offline tegen een lokaal gecachete JWKS, met strikte controle op audience, issuer en het toegestane algoritme. Dat is het soort keuze dat in een MVP vaak overgeslagen wordt en later een securityherstel kost.
Daarnaast stond er vanaf de eerste weken een CI-pijplijn met tagged-release-deploys via SSH: releases zijn benoembaar en terug te draaien, ook voordat er ook maar één gebruiker was. Het geheel groeide in 59 commits van leeg naar draaiend.
2. Een Flutter-prototype voor stakeholder-iteratie
Parallel liep een prototype in Flutter, gebouwd om keuzes af te dwingen in plaats van om code op te leveren. Elf schermen en vier complete user flows: genoeg om de route van lesoverzicht tot bevestigde boeking helemaal door te klikken.
Omdat dezelfde codebase ook naar het web compileert — navigatie via go_router, state via Riverpod, Material 3 als vormgeving — konden de stakeholders het prototype gewoon in hun browser openen. Geen installatie, geen testflight-uitnodiging, en dus een lage drempel om er nog een ronde overheen te doen.
Het prototype was expliciet gereedschap voor besluitvorming, geen voorloper van de productiecode. Het doel was de scope van de launch scherp krijgen — welke flows erin moesten en welke naar later konden.
3. Een toolkeuze die is losgelaten en vastgelegd
De FlutterFlow AI-route is bewust afgebroken toen duidelijk werd dat het per-bericht-model niet paste bij de manier van werken. Daarna zijn we overgestapt op plain Flutter, waarbij iteratiesnelheid niet meer gekoppeld was aan een verbruiksmeter.
Die afweging is gedocumenteerd in plaats van stilzwijgend gemaakt, zodat de opdrachtgever kan navertellen waarom er halverwege van gereedschap is gewisseld.
Ontwerpdoel van deze aanpak: een launch die goedkoop genoeg is om fout te mogen gaan, met een fundament dat een tweede leven aankan. Dit is de gekozen ontwerprichting bij de start van het project — geen na de lancering gemeten uitkomst.
4. Opgegaan in het multi-tenant platform
Het product is inmiddels onderdeel van het multi-tenant platform van de moederorganisatie: een eigen React Native-app met een eigen design-package, in hetzelfde monorepo als de rest. Daarmee hergebruikt het de authenticatie, het databasefundament en de CI-pijplijn die daar al stonden, terwijl het qua interface en doelgroep een eigen product blijft.
Dat is precies de route waarvoor het MVP was opgezet: eerst zelfstandig aantonen dat het product bestaansrecht heeft, daarna de infrastructuurkosten delen met het platform in plaats van ze te verdubbelen.
Fase 2 is planning, geen opgeleverde functionaliteit
Het uitbreiden van het platform met kraamzorgdiensten staat gepland voor september-oktober 2026. Die functionaliteit is op het moment van schrijven niet gebouwd en niet opgeleverd — de case beschrijft uitsluitend de gelanceerde eerste fase.
Wat het opleverde
Greenfield product gelanceerd
Greenfield boekingsplatform gelanceerd in juli 2026: API, prototype-cyclus en integratie in het platform van de moederorganisatie
- 59
- Commits waarin de Fastify/PostgreSQL-API met versiebeheerde node-pg-migrate-migraties vanaf nul is opgebouwd
- 11
- Schermen in het Flutter-prototype voor stakeholder-besluitvorming, een codebase voor iOS, Android en web
- 4
- Complete user flows klikbaar gemaakt voordat de scope van de launch werd vastgezet
- JWKS
- Firebase-authenticatie met offline JWKS-verificatie en strikte audience-, issuer- en algoritmecontrole
- CI/CD
- CI met tagged releases en SSH-deploy vanaf de eerste weken, dus benoembare en terugdraaibare versies
- monorepo
- Later opgegaan in het multi-tenant platform als eigen app plus design-package, met hergebruik van auth, database en CI
Vergelijkbare cases
Een Britse thuiszorgorganisatie (domiciliary care, naam onder NDA)Legacy thuiszorg-platform gemoderniseerd + Nourish-koppeling
21defecten gefixt (waarvan 2 kritiek)
Een Britse thuiszorgorganisatie (domiciliary care, naam onder NDA)Nieuw multi-tenant zorgplatform voor de thuiszorg
RLStenant-isolatie als release-gate
Een Britse thuiszorgorganisatie (domiciliary care, naam onder NDA)Zorg-app op maat: van no-code FlutterFlow naar React Native
3maatwerk-apps in ontwikkeling
Klaar voor zulke resultaten?
Gratis AI-scan: binnen 48 uur een rapport met de AI-kansen met de hoogste ROI voor jouw bedrijf — concreet, geen verkooppraatje.