Hoe voorkom je dat je vastzit aan je vibecode-tool?

Vendor lock-in betekent dat je zo afhankelijk bent van één leverancier dat overstappen moeilijk of duur is. Bij vibecoden is die leverancier je bouwtool.

Dat is niet per se erg. Zolang de tool doet wat je nodig hebt, voor een prijs die past, is er geen reden om weg te gaan. Het wordt een probleem als de tool zijn prijzen of voorwaarden verandert, als je project tegen grenzen van de tool aanloopt, of als je een ontwikkelaar wilt laten meewerken die niet in die tool werkt.

Dan wil je kunnen kiezen. Daarvoor moet je weten waar je afhankelijk bent.

Een gevibecodeed project bestaat uit een paar lagen. Per laag kan de afhankelijkheid anders zijn:

• De code. Kun je die downloaden of naar GitHub zetten? Bij de meeste bekende tools kan dat. Lovable kan bijvoorbeeld twee kanten op synchroniseren (opent in een nieuw tabblad)¹ met GitHub, GitLab of Bitbucket.
• De database. Gebruikt je project de ingebouwde database van de tool, of een eigen Supabase-project? Een eigen project op je eigen account kun je meenemen; een ingebouwde database moet je exporteren en elders weer opzetten.
• Inloggen. Accounts van je gebruikers staan bij een inlogdienst. Verhuizen betekent die accounts overzetten, en soms dat gebruikers een nieuw wachtwoord moeten kiezen.
• Hosting. Meestal het makkelijkst te verhuizen, als de code in GitHub staat (opent in een nieuw tabblad)². Zie Hosting en een eigen domein.
• Functies van de tool zelf. Bijvoorbeeld een ingebouwde AI-koppeling of een tool-specifieke manier van bestanden opslaan. Die werken buiten de tool niet vanzelf.

Het komt per laag neer op één vraag: waar staat die nu, en op wiens account? Alles wat op het account van de tool staat en niet op het jouwe, is een punt van afhankelijkheid.

GitHub is een dienst waar code bewaard wordt in een repository (opent in een nieuw tabblad)³: een map met alle bestanden van je project en de volledige geschiedenis van elke wijziging. Je kunt zien wat er wanneer veranderde en elke eerdere versie terughalen.

Waarom je dat wilt, ook als je zelf nooit code leest:

• Je hebt een kopie buiten je tool. Stopt de tool of raakt je account geblokkeerd, dan heb je je code nog.
• Een ontwikkelaar kan meekijken of meewerken zonder dat hij in jouw tool hoeft te werken.
• Je kunt verder werken in een programmeerhulp als Cursor of Claude Code. Zie Welke tool past bij jou?
• Je kunt je project bij een andere hostingdienst laten draaien.

Belangrijk is dat de repository op je eigen GitHub-account staat, dat hij privé is, tenzij je bewust open source wilt zijn, en dat er geen geheime sleutels in staan. Zie Is mijn app veilig? Dat zetten we voor je op.

Met eigen code bedoelen we: je project staat in je eigen repository, draait op diensten op je eigen accounts, en wordt onderhouden met gewone programmeergereedschappen in plaats van alleen de chat van een bouwtool.

Signalen dat het tijd kan zijn:

• De AI lost fouten niet meer op, of maakt bij elke oplossing iets anders stuk.
• Je hebt functies nodig die je tool niet ondersteunt.
• De kosten van je tool groeien sneller dan je project. Zie Wat kost het draaien?
• Je hebt betalende klanten en wilt zeker zijn van beveiliging, back-ups en onderhoud.
• Je wilt een ontwikkelaar of team laten meewerken.

Geen van deze signalen betekent dat je project mislukt is. Het betekent dat het groter is geworden dan een prototype.

Een overstap hoeft geen herbouw te zijn. Vaak gaat het in stappen:

1. Code naar GitHub. Als dat nog niet zo is.
2. Een ontwikkelaar beoordeelt de code. Wat kan blijven, wat moet anders, waar zitten de risico's?
3. Eerst de fundering. Beveiliging, database, back-ups en een testomgeving op orde.
4. Dan verhuizen. Hosting, database en inloggen naar eigen accounts, laag voor laag, met je gebruikers zo min mogelijk last.
5. Daarna verder bouwen, met of zonder AI, maar met iemand die de code kent.

Sommige makers doen dit zelf, met een programmeerhulp en veel geduld. Je kunt het ook uit handen geven. Wij begeleiden die overstap: we beoordelen je code, zetten de fundering op orde en verhuizen je project laag voor laag. Meer over die keuze lees je in Wanneer haal je een ontwikkelaar erbij? en Van vibecode naar maatwerk.