Een no-code AI-platform belooft iets verleidelijks: je beschrijft in gewone taal wat je nodig hebt, een app, een dashboard, een automatisering, en het ding bouwt zichzelf. Geen ontwikkelaar, geen wachtrij bij de IT-afdeling, klaar terwijl je het uitlegt. Voor een ondernemer of een team zonder eigen programmeurs is dat een enorme sprong: werk dat vroeger een offertetraject en weken bouwtijd kostte, staat nu voor de lunch live.
Maar er is een tweede vraag die pas opspeelt als je er al maanden op draait: van wie is dit eigenlijk, en kom ik er weer uit? Zolang alles werkt, voelt die vraag academisch. Ze wordt concreet op het slechtste moment: als de prijs verdubbelt, als een functie verdwijnt, of als het platform zelf omvalt. Deze gids is voor de ondernemer of het team dat serieus overweegt een deel van de operatie op zo'n bouwplaats te zetten, en dat vooraf wil weten waar de grenzen liggen. Je krijgt een afwegingskader op vier assen, een concrete testvolgorde om een platform te beproeven voordat je erop bouwt, en een eerlijke afweging tussen kant-en-klaar en maatwerk.
Wat een no-code AI-bouwplaats eigenlijk is
Een no-code AI-bouwplaats is een platform waarop je een toepassing bouwt door hem te beschrijven in plaats van te programmeren. Je typt wat je wilt, zoals je het aan een collega zou uitleggen, en een AI-model zet er schermen, logica en koppelingen van. Het genre kreeg een flinke duw toen Prosus zijn Toqan-platform openstelde met ToqanClaw en de AI-assistent Zapia, gericht op miljoenen ondernemers en horecazaken zonder technisch team. Daarnaast is er een breed veld van app-bouwers als Lovable, Bolt, Base44 en Bubble die op dezelfde belofte draaien.
Wat je ermee bouwt, loopt uiteen: interne apps en dashboards, terugkerende rapportages, een kennisbank over je eigen documenten, geplande taken en meldingen, of meerstaps-automatiseringen die meerdere AI-agents aansturen. ToqanClaw zelf routeert daarbij over meer dan twintig modellen en belooft dat je data onder je eigen controle blijft en niet wordt gebruikt om modellen van derden te trainen. Dat klinkt goed, en het kan ook goed zijn. Maar 'je data blijft van jou' en 'je kunt je data en je app meenemen' zijn twee verschillende beloftes, en juist die tweede bepaalt of je vrij blijft.
Wat je nodig hebt
Voordat je begint te bouwen, verzamel je vier dingen. Niet om het ingewikkeld te maken, maar omdat ze later je enige houvast zijn:
- Een helder beeld van wat je bouwt. Welk proces, welke schermen, welke koppelingen. Schrijf het datamodel (welke gegevens, in welke velden, met welke relaties) op papier, los van de tool. Dat document is straks je verzekering.
- Zicht op waar je data landt. Veel bouwplaatsen zetten je gegevens in een managed database, vaak Supabase, die je in theorie bezit maar in de praktijk misschien nooit zelf hebt geopend.
- Een testplan voor export. Bedenk vooraf hoe je gaat controleren of je de app en de data er zonder hulp van de leverancier uit krijgt.
- De contractvoorwaarden. Zoek op wat er staat over eigendom, wat er met je invoer gebeurt (training), en welke opzegtermijn geldt als het platform stopt.
Wie eerst wil bepalen welk werk überhaupt geschikt is om te automatiseren en in welke volgorde, kan met een scorekaart welke processen je als eerste automatiseert wegen voordat je een platform kiest.
De vier assen waarop je vastloopt
Lock-in bij een AI-bouwplaats sluipt er langs vier assen in. Samen bepalen ze hoe vrij je blijft.
| As | De vraag | Waar het misgaat |
|---|---|---|
| Data-export | Kun jij, zonder de leverancier, je data eruit halen? | Data staat in een managed database (vaak Supabase) waar je nooit zelf hebt ingelogd |
| Code-eigenaarschap | Kun je de gegenereerde app ergens anders draaien? | 'Export' bestaat, maar de code hangt vast aan de runtime en build-pijplijn van het platform |
| Integraties | Lopen koppelingen via directe API's of via een platform-wrapper? | Een platformkoppeling werkt alleen zolang het platform hem onderhoudt |
| Kennis | Snapt iemand hoe het in elkaar zit? | Een model nam beslissingen die niet zijn gelogd, uitgelegd of overgedragen |
Deze vier assen zijn de kern van je afweging. Wil je breder kijken naar afhankelijkheid over al je systemen, dan helpt het om de lock-in-risico's per systeem in kaart te brengen met een vijf-assen-methode en een zelftest.
Zo test je een bouwplaats voordat je erop bouwt
Een no-code AI-bouwplaats beoordeel je niet op de demo, maar op je vertrek. Bouw eerst iets kleins en echts, en toets dan in vier stappen of je de app, de data en de koppelingen zonder het platform kunt meenemen. Slaag je daar niet voor, dan weet je dat wat je bouwt in feite geleend is.
Loop deze volgorde af voordat je iets bedrijfskritisch toevertrouwt:
- Bouw een klein, echt onderdeel. Niet de hele operatie, maar één afgebakend proces met echte data. Zo test je het platform op jouw werkelijkheid, niet op een voorbeeld.
- Doe de export-test, en draai het elders. De vraag is niet of er een exportknop is, maar of de geëxporteerde app ergens anders draait zonder de infrastructuur van het platform. Zet de export op een neutrale hosting en kijk of hij start.
- Haal je data er zelf uit. Log in op de onderliggende database en exporteer je gegevens zonder de leverancier te bellen. Lukt dat niet binnen een uur, dan is je toegang afhankelijk van hun goede wil, en bij een plotselinge sluiting is dat venster kort.
- Controleer je koppelingen en de voorwaarden. Ga per integratie na of hij via een directe API loopt (overdraagbaar) of via een platform-wrapper (verdwijnt met het platform). Lees tot slot na wat de voorwaarden zeggen over training op je data en de opzegtermijn.
In een vergelijkende test van vijf AI-bouwers bleek dit verschil hard: waar het ene platform je volledige, overdraagbare code geeft, biedt een ander geen betekenisvolle export en zit je muurvast. De marketingpagina zegt daar zelden iets nuttigs over; alleen je eigen test doet dat.
Valkuilen
- De laatste 20 procent. Bouwplaatsen brengen je razendsnel tot een werkend prototype, maar lopen vast op de laatste loodjes: maatwerk-logica, uitzonderingen, complexe koppelingen. Een bekende verzuchting is dat de eerste 80 procent je een genie laat voelen en de laatste 20 procent een gijzelaar.
- 'Export' is niet hetzelfde als 'draaibaar'. Geëxporteerde code hangt vaak vast aan de runtime, de componenten en de build-pijplijn van het platform. Je hebt bestanden, maar geen draaiende app.
- De database waar je nooit inlogde. Je data staat in een managed database die je bezit, maar als je er nooit direct verbinding mee maakte, ontdek je pas bij een storing of sluiting hoe je erbij komt.
- Onzichtbare beslissingen. Een app die door een model is gebouwd, zit vol keuzes die niet zijn gelogd of uitgelegd. Wil iemand hem later onderhouden of uitbreiden, dan begint die bij nul.
- Economische lock-in en omvallen. Ook zonder technische drempel houdt een prijsverhoging of een overname je vast. Het uiterste geval is een platform dat verdwijnt: Builder.ai, dat 450 miljoen dollar had opgehaald en toch omviel, waarna klanten maar dagen hadden om iets te regelen. Reken op de mogelijkheid, niet op de belofte.
Kant-en-klaar vs. maatwerk
De keuze is geen alles-of-niets. Er is een middenweg, en welke past hangt af van hoe kritisch en hoe uniek het proces is.
| No-code bouwplaats | Bouwplaats plus exit-plan | Maatwerk / eigen code | |
|---|---|---|---|
| Snelheid live | Uren tot dagen | Dagen | Weken |
| Kosten start | Laag (abonnement per app) | Laag tot midden | Hoog vooraf |
| Eigenaarschap code | Meestal geen echte export | Gedeeltelijk, mits export getest | Volledig |
| Waar het knelt | De laatste 20% en het weggaan | Onderhoud van de export | Vooraf investeren, langer bouwen |
| Past bij | Intern, niet-kritisch, snel valideren | Kern die kan groeien | Bedrijfskritisch, uniek proces |
Voor niet-kritische, snel te valideren zaken is een bouwplaats vaak precies goed: laag in de kosten, in uren live. De kosten lopen grofweg van twintig tot vijftig dollar per maand per app, en flink hoger voor enterprise-varianten, wat pas telt zodra je serieus opschaalt. Zodra iets de kern van je bedrijf raakt, verschuift de weegschaal naar eigenaarschap. Dat hoeft niet meteen volledig maatwerk te zijn: je kunt een bouwplaats gebruiken met een getest exit-plan, of de AI-laag bewust leverancier-onafhankelijk opzetten. Wie de modellaag wil kunnen wisselen, zet zijn AI-stack op met een model-router en een open-weight uitwijk; wie precies wil weten welke motor er onder een dienst draait, checkt welk AI-model onder je SaaS draait en of je kunt wisselen. En laat je maatwerk bouwen, leg dan broncode-eigendom en escrow vast bij AI-geschreven software zodat je er ook zonder je bouwer bij kunt.
Gaat het om pure workflow-automatisering, los van een app-bouwer, dan is de afweging vergelijkbaar; daar kies je tussen n8n, Make en Zapier op volume, datagevoeligheid en logica.
De vraag die telt
De echte vraag bij een no-code AI-bouwplaats is niet of je er snel iets mee bouwt, want dat lukt bijna altijd. De vraag is of wat je bouwt van jou is, en of je vrij blijft om te vertrekken. Bouw het onbelangrijke snel en zorgeloos op zo'n platform. Maar zodra iets bedrijfskritisch wordt, koop je met eigenaarschap iets terug wat geen enkele demo je laat zien: de zekerheid dat je morgen nog aan het stuur zit. Snel bouwen is makkelijk geworden. Kunnen weggaan is de vaardigheid die telt.
Veelgestelde vragen
Bouwen met een exit ingebouwd
Twijfel je of een no-code platform je straks klemzet? Ik denk met je mee over wat je veilig zelf bouwt en bouw waar het telt maatwerk dat van jou blijft, met je data en code in eigen hand.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
