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:
- 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.
