Zorg-app op maat: van no-code FlutterFlow naar React Native

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

Ten eerste 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. Ten tweede kosten per wijziging: bij een platform met per-gebruik-metering schaalt de rekening mee met de betrokkenheid van de klant, wat een pervers effect heeft op de kwaliteit. Ten derde 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.

1. Een app voor zorgmedewerkers onderweg — de dagelijkse werkomgeving voor wie tussen cliënten door op zijn telefoon werkt.
2. Een app voor cliënten en familie — inzicht in de eigen zorg, aan de ontvangende kant.
3. 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.