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. Dat is 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.