Britse kraamzorg-startup — zusterproduct van een bestaande klant in de Britse thuiszorg, naam onder NDA
Echte first-party klantcase, geanonimiseerd op verzoek (zorgsector, gevoelige data). Het product is in juli 2026 gelanceerd: er zijn nog geen gebruikers-, boekings- of omzetcijfers. De genoemde resultaten zijn geleverde scope en techniek, geen gemeten business-resultaten. Fase 2 (kraamzorgdiensten) is planning, geen opgeleverde functionaliteit.
Een Britse thuiszorgorganisatie waarvoor CleverTech 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:
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.
CleverTech bouwde het product als zelfstandig MVP met een volwassen fundament: klein in functionaliteit, niet klein in techniek. Het werk liep langs vier stappen.
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.
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.
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.
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.
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.
Greenfield product gelanceerd
Greenfield boekingsplatform gelanceerd in juli 2026: API, prototype-cyclus en integratie in het platform van de moederorganisatie
Legacy thuiszorg-platform gemoderniseerd + Nourish-koppeling
Nieuw multi-tenant zorgplatform voor de thuiszorg
Zorg-app op maat: van no-code FlutterFlow naar React Native
We bouwen voor jouw bedrijf wat we voor deze klant bouwden — met heldere afspraken vooraf. 30 min vrijblijvende scoping.
