Zorg-app op maat: van no-code FlutterFlow naar React Native
De uitdaging
Een thuiszorgorganisatie in het Verenigd Koninkrijk levert CQC-gereguleerde zorg bij mensen thuis. Twee groepen zitten daarbij vrijwel permanent op hun telefoon: de zorgmedewerkers die de hele dag onderweg zijn tussen adressen, en de cliënten en hun familie die willen weten wie er komt en wanneer.
Voor allebei bestond al een app — een medewerkers-app en een klanten-app, gebouwd in FlutterFlow (versie 2.0.9) met Firebase eronder. FlutterFlow is een no-code/low-code platform: je klikt een app in elkaar in plaats van hem te programmeren.
Precies wat je wilt als je snel iets werkends nodig hebt. Het werd een probleem toen die apps moesten meebewegen met een backend die volledig op maat werd herbouwd.
De vraag "een nieuwe zorg-app laten maken" bleek daarmee vooral een keuzevraag. Vier dingen dwongen die keuze af:
- De apps hingen aan een systeem dat verdween. Beide FlutterFlow-apps waren gebouwd op de datastructuur van het oude platform. Zolang die backend werd vervangen door een nieuw, multi-tenant systeem, was elke app-wijziging een wijziging aan twee kanten tegelijk.
- De iteratiesnelheid liep vast op het verdienmodel van de tool. In het prototypetraject van mei 2026 is FlutterFlow AI expliciet losgelaten, met de reden erbij gedocumenteerd: de metering per bericht paste niet bij het intensieve heen-en-weer met stakeholders dat dit ontwerp nodig had. Wie tientallen keren per dag een scherm wil bijstellen, wil niet bij elke iteratie een teller horen tikken.
- Integratie met een maatwerk-backend is geen no-code-terrein. Het nieuwe platform draait op PostgreSQL met row-level security en een tenant-gebonden API. De apps raken bovendien de roosterengine, die alternerende zorgroosters van twee en vier weken aankan en handmatig gewijzigde boekingen beschermt tegen overschrijven. Dat soort logica laat zich niet in een klikbare koppeling vangen.
- Er waren geen twee doelgroepen, maar drie. Naast zorgmedewerkers en cliënten is er een apart kraamzorg- en prenataal product met een eigen gebruikersgroep en een eigen verhaal.
De opdracht werd daarmee scherper dan "vervang de apps": bepaal welke techniek een app voor thuiszorgmedewerkers de komende jaren draagt, en zorg dat de overstap kan zonder de lopende zorgverlening te verstoren.
De aanpak en oplossing
CleverTech AI behandelde de app-laag als een aparte ontwerpbeslissing, niet als een bijproduct van de platformbouw. Het traject liep langs vier stappen, van prototype naar definitieve richting.
1. Eerst een prototype, in plain Flutter
Voordat er een woord over architectuur werd gezegd, is er in mei 2026 een werkend prototype gebouwd: 11 schermen en 4 user flows, in Material 3-vormgeving, met go_router voor navigatie en Riverpod voor state — één codebase die op iOS, Android en web draait. Bewust plain Flutter, dus zonder de FlutterFlow-laag erboven.
Zo kon het gesprek met de organisatie over schermen en flows gaan, terwijl het bouwtempo niet meer afhing van een externe metering.
Ontwerpdoel van dit prototype: de stakeholders laten zien en bijsturen wat ze zouden krijgen, vóórdat de definitieve techniekkeuze viel. Dat is de bedoeling waarmee het is gebouwd — geen na oplevering gemeten uitkomst.
2. FlutterFlow of maatwerk: de eerlijke afweging
De les uit dit traject is niet "no-code is slecht". No-code deed precies waarvoor het bedoeld is: het bracht deze organisatie zonder ontwikkelteam aan twee draaiende apps. De grens werd op drie punten bereikt.
- Iteratiesnelheid — bij intensieve stakeholder-rondes is een omgeving nodig waarin een wijziging niets extra's kost, anders wordt er minder geïtereerd dan het ontwerp verdient.
- Kosten per wijziging — bij per-gebruik-metering schaalt de rekening mee met de betrokkenheid van de klant, wat een pervers effect heeft op de kwaliteit.
- Integratiediepte — een maatwerk-backend met tenant-isolatie, row-level security en een eigen roosterengine vraagt een API-client die je zelf in de hand hebt.
Waar die drie punten allemaal spelen, kantelt de afweging naar maatwerk. Waar ze niet spelen — een eenvoudige, op zichzelf staande app zonder diepe koppeling — blijft no-code een verstandige, goedkopere start.
Voor de bredere afweging tussen native, cross-platform en PWA staat de uitwerking op app laten ontwikkelen.
3. Drie React Native (Expo)-apps in één monorepo
De definitieve richting, vanaf juni 2026 vastgelegd in de platform-monorepo, is een React Native-app-familie op Expo: drie apps naast elkaar, met gedeelde packages voor de API-client en het design.
- Een app voor zorgmedewerkers onderweg — de dagelijkse werkomgeving voor wie tussen cliënten door op zijn telefoon werkt.
- Een app voor cliënten en familie — inzicht in de eigen zorg, aan de ontvangende kant.
- Een app voor het kraamzorg- en prenatale product — een eigen propositie met een eigen gebruikersgroep.
Het gedeelde-packages-model is hier de kern van de winst: één API-client en één designlaag betekent dat een wijziging in het contract met de backend op één plek landt in plaats van in drie apps. Dat is precies het voordeel dat wegvalt als je drie no-code-apps los van elkaar onderhoudt.
4. Aangesloten op het platform, met de beveiliging vooraan
De medewerkers-app hangt rechtstreeks aan het nieuwe multi-tenant platform: PostgreSQL met row-level security, een tenant-gebonden API, en Playwright end-to-end-tests in de CI-pijplijn. Authenticatie loopt via Firebase JWT-verificatie met offline JWKS en strikte controles op aud, iss en alg — hetzelfde patroon dat in het kraamzorgproduct is toegepast.
In een gereguleerde zorgcontext is dat geen detail: een app die roosters en cliëntgegevens toont, mag onder geen beding data van een andere organisatie in beeld krijgen.
De apps raken daarmee ook de roosterengine met zijn twee- en vierweekse alternerende roosters, inclusief de bescherming van boekingen die handmatig zijn aangepast — een planner die iets bewust verzet, wil dat niet door een automatische generatieronde overschreven zien.
Status: de legacy-apps draaien nog
Belangrijk voor het eerlijke beeld: de nieuwe apps zijn in ontwikkeling. De bestaande FlutterFlow-apps staan tot de platformmigratie is afgerond gewoon in productie en blijven de zorg dragen.
Er zijn dus geen download- of gebruikscijfers van de nieuwe apps, en die worden hier ook niet gesuggereerd. Wat wél overdraagbaar is, is de afweging zelf: wanneer een mobiele app op maat laten maken meer oplevert dan een no-code-app doorontwikkelen, en waarom die grens meestal bij de integratie met je eigen backend ligt.
Wat het opleverde
Drie maatwerk-apps op React Native (Expo) in ontwikkeling: zorgmedewerkers, cliënten en familie, en het kraamzorgproduct
- 11 + 4
- Plain-Flutter-prototype met 11 schermen en 4 user flows in één codebase voor iOS, Android en web
- 1API
- Gedeelde packages voor API-client en design, zodat een backend-wijziging op één plek landt in plaats van in drie apps
- RLS
- Medewerkers-app aangesloten op het multi-tenant platform met PostgreSQL row-level security en een tenant-gebonden API
- JWT/JWKS
- Firebase JWT-verificatie met offline JWKS en strikte aud-, iss- en alg-checks op de API
- E2E
- Playwright end-to-end-tests in de CI-pijplijn van het platform waarop de apps aansluiten
- 2 + 4 wk
- Roosterengine met alternerende zorgroosters van twee en vier weken, met bescherming van handmatig gewijzigde boekingen
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
Britse kraamzorg-startup — zusterproduct van een bestaande klant in de Britse thuiszorg, naam onder NDABoekingsplatform voor prenatale lessen: van MVP naar platformonderdeel
MVPgreenfield product gelanceerd
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.