Elke vibe-coding pitch noemt code-eigendom ergens in de eerste alinea. Exporteren naar GitHub. Geen eigen bestandsformaat. Neem het mee. Het klinkt als het tegenovergestelde van lock-in, en voor het deel van je app dat gewoon React-componenten is, klopt dat ook meestal.
Het deel dat nooit in de pitch voorkomt, is de database. En daar leeft de eigenlijke app.
Wat “export” écht exporteert
Bolt en Base44 bieden allebei eenvoudige GitHub-sync voor de frontend, en Lovable doet hetzelfde voor zijn React/TypeScript-output. Als je app een marketingsite of een statisch prototype is, is die export bijna alles, en kun je de repo aan een developer geven en zonder zorgen vertrekken.
Business-apps zijn dat niet. Zodra je build logins, rollen en echte records heeft, zit het grootste deel van wat hem laat werken niet in de componentenboom, maar in het schema, de auth-regels en de rechtenlogica erachter. Dat is precies de laag die deze platforms liever niet loslaten.
Base44 maakt dit expliciet in plaats van impliciet: reviewers merken op dat frontend-code naar GitHub exporteert, maar de database en backend volledig gehost blijven op de infrastructuur van Base44 en niet rechtstreeks kunnen worden aangepast of geëxporteerd. Eén Base44-bouwer die zijn eigen bestanden van het platform probeerde te halen, zei het onomwonden op Reddit: “Ik zie geen src-bestanden in de toegankelijke bestanden, dus ik ben bang dat ik een jaar builder-tier moet betalen om de build zelfs maar van Base44 af te krijgen. Dat is $480, nogal absurd.” Je kunt technisch gezien vertrekken. Je betaalt eerst een abonnement om te ontdekken waarmee.
Het Hotel California-probleem
De klachten over Lovable gaan nog een stap verder, want het probleem is niet alleen wat niet exporteert, het is wat verandert zonder te vragen. Een Reddit-thread die een referentiepunt in de community is geworden, beschrijft hoe Lovable’s AI op eigen initiatief de privé Supabase-database van een bouwer migreert naar Lovable Cloud, zonder expliciete toestemming, en noemt het platform “een Hotel California voor je database: je kunt inchecken, maar nooit meer weg.”
Dat is een ander soort probleem dan “de exportknop ontbreekt.” Het platform verplaatst in stilte precies het ding dat je zou moeten exporteren. Als je ervan uitging dat je data in je eigen Supabase-project stond omdat de tool zich zo profileert, is het achteraf anders ontdekken precies het soort verrassing dat uitgroeit tot een waarschuwende Reddit-thread die andere bouwers later vinden, vlak voordat ze dezelfde aanname maken.
De backend-lock-in van Base44 leidt vanuit een andere hoek tot dezelfde conclusie: een Product Hunt-reviewer merkte op dat zelfs waar frontend-code netjes exporteert, de database en backend gevangen blijven in de gesloten infrastructuur van Base44, waardoor echte databasemigratie onmogelijk is. Twee platforms, twee mechanismen, hetzelfde resultaat: het deel van de app met je echte bedrijfsdata is precies het deel dat je niet makkelijk meeneemt.
Waarom dit oploopt in plaats van gelijk blijft
Niets hiervan doet er op dag één veel toe, want dag één is een demo met voorbeelddata. Het begint pas mee te tellen zodra de app echte gebruikers heeft en het schema groter is geworden dan wat één prompt oorspronkelijk opzette.
Schema-schuld is het mechanisme dat “we migreren wel een keer” verandert in “we zitten vast.” Bouwers die al lang met Lovable werken, melden dat het prima werkt om de AI het databaseschema te laten ontwerpen, maar dat het na zes tot negen maanden zoveel schema-schuld oplevert dat het toevoegen van één nieuw veld tientallen onderliggende workflows moet herschrijven. Op dat punt is migreren geen kwestie van een tabel kopiëren, maar van het ontwarren van een systeem dat niemand tijdens het bouwen volledig heeft gedocumenteerd. Datzelfde onderzoek geeft aan dat ervaren bouwers Lovable inmiddels afraden voor alles wat langer dan 18 tot 24 maanden moet meegaan, en adviseren om vóór die schuld verder oploopt over te stappen op een code-first stack.
Zet dat tegenover een platform dat zichzelf ook onder je vandaan bijwerkt. Bouwers op Lovable melden dat de eigen updates van het platform regelmatig bestaande klantapps stukmaken, tot het punt dat sommigen klanten nu een maandelijkse onderhoudsvergoeding rekenen alleen om de regressies op te vangen die het platform zelf veroorzaakt. Je zit niet alleen vast aan de database. Je zit ook vast aan het herstellen van schade die de leverancier veroorzaakt terwijl je vastzit.
“Ik ben oprecht bang voor Base44, omdat ik het fundament van mijn bedrijf op dat platform bouw… iets werkt vandaag en morgen halen ze het weer weg.” - Base44-gebruiker, r/Base44
Wat het risico écht verkleint
We gaan niet doen alsof er een versie van “gehost platform” bestaat die nul lock-in betekent. Softr is ook gehost, en als je je account sluit, loop je niet weg met een overdraagbare app, net zomin als bij Lovable of Base44. De eerlijke vraag is niet “kan ik lock-in volledig vermijden,” maar “hoeveel van mijn data blijft bereikbaar terwijl ik het platform gebruik, en hoe erg is de uitgang als ik die ooit nodig heb.”
Bij die vraag telt het mechanisme zwaarder dan de marketingtekst. Een paar dingen die het waard zijn om te checken voordat je iets bouwt dat echt moet blijven staan, op welk platform dan ook:
- Kan een externe tool bij je data zonder via de UI van de app te gaan? De database van Softr zelf biedt een MCP-server (
mcp.softr.io) plus een REST API, zodat tools als Claude, Cursor of een script je schema in natuurlijke taal kunnen lezen, schrijven of herstructureren terwijl je nog aan het bouwen bent. Softr presenteert dit expliciet als een manier om lock-in te voorkomen door de database toegankelijk te houden buiten één interface, wat een andere belofte is dan “je kunt uiteindelijk code exporteren.” - Verplaatst het platform in stilte je infrastructuur zonder het te melden? Dit is specifiek de klacht over Lovable. Als je platform kan bepalen waar je data staat als onderdeel van een AI-actie, vraag dan wat dat triggert en of je dat kunt uitzetten.
- Wat kost het echt om het schema na zes maanden te wijzigen? Niet op dag één, wanneer alles een vers AI-opzetje is, maar nadat echt gebruik de data heeft gevormd. Schema-schuld is de langzame versie van lock-in, en het is degene die niet op een prijspagina verschijnt.
Als de app echt een prototype of persoonlijk project is, zou niets hiervan je dit weekend moeten tegenhouden om hem toch te vibe-coden, exporteerbare code en al. Maar als het een klantportaal, een intern hulpmiddel of iets met echte gebruikers en echte records is, dan zijn het Day Two-probleem en het lock-in-probleem hetzelfde probleem met twee namen: de leidingen waar je op dag één niet bij stilstond, zijn precies wat op dag tweehonderd het lastigst te verplaatsen zijn. Bekijk onze ranking van klantportalen voordat je een fundament kiest waar je niet zomaar vanaf komt.