Hoe vendor lock-in echt werkt bij no-code en AI-bouwers: waarom de app die je bouwde je abonnement misschien niet overleeft, welke exportbeloften geen echte uitgang zijn, vijf vragen die de waarheid blootleggen voordat je je vastlegt, en hoe je bouwsnelheid krijgt zonder eigenaarschap op te geven.
Founders en ondernemers die op een no-code of AI-platform hebben gebouwd, of dat van plan zijn, en de vrijheid willen houden om te vertrekken.
- Een scherp beeld van wat lock-in is en wanneer het je geld gaat kosten
- De nep-exporttest die door elke geruststellende belofte heen prikt
- Vijf vragen die eigenaarschap blootleggen voordat je een project toevertrouwt
De snelste manier om te bouwen kan ongemerkt de duurste plek worden om vast te zitten. Lock-in kondigt zichzelf nooit aan op de prijzenpagina; het verschijnt op de dag dat je probeert te vertrekken en ontdekt dat wat je bouwde niet mee kan. Zo werkt de val echt, zo herken je exports die geen echte uitgang zijn, en zo houd je de snelheid zonder de kooi te dragen.
Lock-in betekent dat wat je bouwde alleen bestaat binnen het platform van één leverancier: de app draait op hun runtime, de logica leeft in hun formaat en de data zit in hun schema. Stop met betalen en de app stopt met werken; wil je weg, dan is er niets draagbaars om mee te nemen. Je bezit een account, geen applicatie. De test is simpel: zou een developer je app kunnen draaien en onderhouden op een server die jij beheert, zonder de leverancier? Zo niet, dan zit je vast.
Wat deze val zo effectief maakt, is dat alles van binnenuit als eigendom voelt. Jij maakte de app, hij draagt jouw merk, je klanten gebruiken hem elke dag. Het gat tussen dat gevoel en de juridisch-technische realiteit verschijnt pas bij de exit, het duurst mogelijke moment om erachter te komen. Tegen die tijd zijn de herbouwkosten je onderhandelingspositie, en de leverancier weet dat.
En de exitdag komt vaker dan mensen plannen: een prijsverhoging die je niet kunt dragen, een feature die het platform nooit gaat bouwen, een overname die de voorwaarden verandert, of simpelweg een product dat uit zijn template groeit. Herbouw op maat kost 15.000 tot 300.000 dollar, en dat is precies het losgeld dat een lock-in-positie aan je leverancier overhandigt.
Omdat kopers leerden vragen naar lock-in, leerden leveranciers antwoorden met features die klinken als vrijheid en niets veranderen. Leer het verschil horen, want de formuleringen zijn zorgvuldig gekozen en de verschillen zijn echt.
Een founder vraagt twee platforms wat er gebeurt bij opzegging. Platform A: “je kunt al je data altijd exporteren”, oftewel CSV-bestanden met rijen. Platform B: “je project is een code-repository; zo draai je hem op elke host”, oftewel het product zelf gaat mee. Beide antwoorden klinken geruststellend in een salesgesprek. Maar slechts één ervan is een uitgang, en het verschil is precies één volledige herbouw waard.
Zou een competente developer kunnen pakken wat je bouwde, het draaien op infrastructuur die jij beheert en het blijven verbeteren met gewone tools, zonder de runtime of toestemming van de leverancier? Ja betekent dat je een applicatie bezit. Al het andere betekent dat je een abonnement bezit.
Stel deze vragen voordat je een echt project aan welk platform dan ook toevertrouwt, en sta op duidelijke antwoorden. Ontwijkende antwoorden zijn ook antwoorden.
Het is verleidelijk om dit alles weg te zetten als een probleem voor later. Dat is een misvatting over hoe de kosten werken: lock-in wordt doorlopend in je positie verrekend, niet alleen bij de exit.
Je migratiekosten zijn het plafond van wat een leverancier je kan rekenen, en wanneer migreren een volledige herbouw betekent, ligt dat plafond erg hoog. Verlengingsonderhandelingen weerspiegelen dat. Eigenaar zijn van je code houdt de leverancier elk jaar eerlijk, omdat weglopen altijd een reële optie blijft.
Elk gesloten platform heeft een grens, en succesvolle producten vinden die: de integratie die het niet gaat ondersteunen, de regel die het model niet kan uitdrukken, de performance die het niet kan leveren. Op een gesloten fundament is die grens een muur waar je achter wacht. Op een open fundament is het de lijn waar je zelf de code begint aan te passen.
Een bedrijf dat draait op software die het bezit, bouwt een asset op: iets dat je overal kunt hosten, aan een developer kunt overdragen of met het bedrijf kunt verkopen. Dezelfde workflows gebouwd binnen een gesloten platform zijn een doorlopende verplichting vermomd als vooruitgang, en due diligence behandelt ze precies zo.
Tien jaar lang was het eerlijke antwoord nee, en die ruil bouwde de no-code-industrie. Visuele bouwers gaven je snelheid en namen je vrijheid; code vanaf nul schrijven gaf je vrijheid en nam je maanden. De meeste mensen kozen rationeel voor snelheid en hoopten dat de muur ver weg zou blijven.
Bouwen met AI heeft die ruil opgelost. Je kunt nu in gewone taal beschrijven wat je wilt, dezelfde dag een werkende applicatie krijgen met een echte database en login, en aan het eind echte, bewerkbare broncode en je eigen data in handen hebben: gehost waar jij kiest, te onderhouden met gewone tools, uit te breiden voorbij elk template. De vriendelijke weg naar binnen vereist niet langer een kooi bij de uitgang.
Houd dus elke tool, ook de nieuwste AI-bouwers, aan de volledige standaard: echte snelheid erin, echt eigenaarschap eruit. Beide bestaan nu samen. Genoegen nemen met slechts één van de twee is een keuze, en met wat je nu weet zou het een dure zijn.
Stel één vraag en sta op een duidelijk antwoord: als ik stop met betalen, kan een competente developer mijn app dan draaien en onderhouden op infrastructuur die ik beheer? Verifieer het daarna in de trial: zoek naar echte broncode en een databaseschema dat je kunt meenemen, niet naar een exportknop die spreadsheets uitspuugt.
Nee. Rijen zonder het schema, de relaties, de logica en de schermen zijn records, geen product. Ze ergens anders gebruiken betekent alles eromheen vanaf nul herbouwen, precies de kosten die lock-in je had moeten besparen.
Niet meer. AI-bouwers maken tegenwoordig in een dag een werkende applicatie van een beschrijving in gewone taal, en laten je echte, bewerkbare code en je eigen data na. De ruil tussen snelheid en eigenaarschap die gesloten platforms rechtvaardigde, bestaat niet meer.
Omdat de kosten oplopen terwijl je blijft: een leverancier die weet dat vertrekken een volledige herbouw betekent, prijst daarnaar, en op de dag dat je iets nodig hebt dat het platform niet kan, wacht je in plaats van te bouwen. Eigenaarschap is een drukmiddel dat je elk jaar in handen hebt, niet alleen een verzekering voor een exit.