Ga naar inhoud
ai architectuur vendor-lock-in migratie 12 min leestijd

Je AI-gebouwde app zit gevangen: zo ontsnap je aan platform vendor lock-in

Rachid Al Maach ·

Je hebt je app in een weekend gebouwd. Een AI-agent schreef de code, deployde het, gaf je een URL. Je liet het aan klanten zien. Het werkte. Je voelde je een genie.

Toen kwam de factuur.

$200 per maand. Niet voor hosting. Niet voor een database. Voor AI-tokens. De agent die je app bouwde draait nu bij elk verzoek, elke wijziging, elke bugfix. Je "gratis" app heeft een abonnement waar je nooit voor hebt getekend.

Welkom bij AI-platform vendor lock-in.

De val

AI-agentplatformen zoals Manus, Lovable, Bolt en anderen beloven hetzelfde: beschrijf je app, laat de AI het bouwen, ship het vandaag. En ze leveren. De app werkt. De landingspagina ziet er goed uit. De formulieren versturen.

Wat ze je niet vertellen is wat er na de lancering gebeurt.

Je code draait op hun infrastructuur. Elke wijziging loopt via hun AI-agent, die tokens verbrandt. Moet je een typefout op je homepage fixen? Dat is een agent-aanroep. Moet je een nieuwe pagina toevoegen? Meer tokens. Moet je debuggen waarom een formulier niet meer werkt? De agent herschrijft de helft van je codebase en rekent je ervoor.

Je bezit geen product. Je huurt er een. En de verhuurder kan de huur verhogen wanneer hij wil.

Waarom dit gebeurt

AI-platformen creëren afhankelijkheid by design. Niet omdat ze kwaadaardig zijn. Omdat hun businessmodel het vereist. Dit is waarom je vastzit:

Geen standaard deployment. Je code draait op hun infrastructuur. Er is geen Docker-container die je kunt downloaden, geen server waar je naar kunt verwijzen, geen deploy-knop die ergens anders werkt. Als je weggaat, stopt je app met werken.

AI-agents draaien bij elke interactie. Anders dan traditionele hosting, waar je code op een server draait en dat is het, routeren deze platformen wijzigingen (en soms requests) via een AI-agent. Dat betekent continu tokenverbruik. De meter stopt nooit.

Gegenereerde code heeft geen structuur. De AI schreef code die werkt, maar er zijn geen tests, geen documentatie, geen consistente architectuur. Het is een verzameling bestanden die toevallig de juiste output produceren. Probeer het zes maanden later te begrijpen.

Platformspecifieke abstracties. Veel platformen wrappen standaardbibliotheken in hun eigen SDK's. Je "React-app" is eigenlijk afhankelijk van platformspecifieke componenten die nergens anders bestaan. Verwijder ze en er rendert niks meer.

Geen versiebeheer. Er is geen git-geschiedenis. Geen branches. Geen manier om te zien wat er wanneer is veranderd. Als de agent iets kapotmaakt, kun je niet terugdraaien. Je vraagt de agent het te fixen, die herschrijft meer code, en je verbrandt meer tokens.

De werkelijke kosten

Laten we de rekening maken voor een reëel scenario.

Je hebt een ledensite gebouwd met een AI-platform. Maandelijkse kosten:

  • AI-tokenkosten: $200-500/maand (schaalt mee met gebruik en wijzigingen)
  • Platformabonnement: $20-50/maand
  • Elke bugfix: 5-20 minuten agent-tijd, meer tokens
  • Elk featureverzoek: nog meer tokens

Dezelfde app op een VPS van $10/maand met Docker: $10/maand. Geen tokenkosten. Geen kosten per wijziging. Je bewerkt een bestand, pusht naar git, het deployt. Klaar.

Over een jaar is het verschil $2.400-6.000 versus $120. En dat is voordat je de onvoorspelbare pieken meetelt wanneer de agent besluit je codebase te "verbeteren."

Maar de kosten die er het meest toe doen zijn niet financieel. Het is controle. Je kunt niet van hostingprovider wisselen. Je kunt geen developer inhuren om onafhankelijk aan je code te werken. Je kunt je app niet verkopen zonder de platformafhankelijkheid mee te verkopen. Je bedrijf is gebouwd op andermans runtime.

Het migratieplan

We hebben vijf productie-apps gemigreerd van een AI-agentplatform. Elke migratie volgde hetzelfde zevenstapenproces. Dit is het draaiboek.

Stap 1: Exporteer alles

Haal je code eruit. De meeste platformen laten je broncode downloaden, ook al maken ze het lastig te vinden. Download elk bestand. Exporteer je database. Sla je omgevingsvariabelen op. Maak screenshots van je platforminstellingen.

Als het platform je geen database-export geeft, check of je de database direct kunt benaderen. Veel platformen gebruiken standaard MySQL of PostgreSQL onder de motorkap.

# Exporteer vanuit het platform (als ze je dat toestaan)
mysqldump -h platform-host -u user -p dbname > backup.sql

# Importeer in je eigen database
mysql -h localhost -u user -p myapp < backup.sql

Sla je omgevingsvariabelen op. Elk geheim, elke API-sleutel, elke configuratiewaarde. Je hebt ze allemaal nodig.

# .env - de configuratie van je app
DATABASE_URL=mysql://user:pass@db:3306/myapp
AUTH_SECRET=jouw_jwt_secret_hier
SMTP_HOST=smtp.sendgrid.net
SMTP_USER=apikey
SMTP_PASS=jouw_sendgrid_key
APP_URL=https://jouwdomein.nl

Stap 2: Audit de codebase

Voordat je iets aanraakt, lees de code. Alles. Je moet drie vragen beantwoorden:

  1. Wat werkt er daadwerkelijk? Niet wat de agent zei dat het heeft gebouwd. Wat er echt functioneert als je door de app klikt.
  2. Wat is platformspecifiek? Zoek naar imports van de SDK van het platform, API-calls naar hun endpoints, componenten die alleen in hun ecosysteem bestaan.
  3. Wat is AI-spaghetticode? Code die de agent drie keer heeft herschreven. Dode functies. Ongebruikte bestanden. Dependencies geïnstalleerd maar nooit geïmporteerd. Elke AI-gegenereerde codebase heeft deze. Identificeer ze nu.

Maak een lijst. "Werkt, behouden." "Werkt, maar platformverwijzingen moeten eruit." "Verwijderen." Deze audit bespaart je uren verwarring later.

Stap 3: Zet echte infrastructuur op

Je hebt drie dingen nodig: een server, Docker en een deployment-pipeline.

Een VPS van een willekeurige provider werkt. Hetzner, DigitalOcean, Vultr. Kies er een. Installeer Docker. Maak een docker-compose-bestand dat je app en database beschrijft.

version: "3.8"
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=mysql://user:pass@db:3306/myapp
      - NODE_ENV=production
    depends_on:
      - db

  db:
    image: mysql:8
    volumes:
      - db_data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=secure_password
      - MYSQL_DATABASE=myapp

volumes:
  db_data:

Maak een Dockerfile voor je applicatie:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/index.js"]

Dit is je complete deploymentverhaal. Geen AI-agents. Geen tokenverbruik. Push code, bouw container, draai het.

Stap 4: Databasemigratie

Als je in Stap 1 een database-export hebt gekregen, importeer deze in je zelfgehoste database. Verifieer de data. Controleer of je tabellen, rijen en relaties intact zijn.

Als het platform een niet-standaard database of een proprietary datalaag gebruikte, moet je een migratiescript schrijven. Dit is het moeilijkste deel. Sommige platformen slaan data op in formaten die niet netjes mappen naar standaarddatabases. Reken op extra tijd hiervoor.

Stap 5: Fix platformspecifieke code

Hier betaalt de audit van Stap 2 zich terug. Loop elke platformspecifieke verwijzing door en vervang het:

  • Platform-SDK-imports: Vervang door standaardbibliotheken. Als ze een custom auth-wrapper gebruikten, schakel over naar een standaard JWT-library. Als ze een proprietary databaseclient gebruikten, schakel over naar een standaard ORM.
  • Hardcoded platform-URL's: Vervang door omgevingsvariabelen die naar je eigen domein wijzen.
  • Platformspecifieke componenten: Vervang door standaard React-componenten, of welk framework je ook gebruikt. De meeste platformcomponenten zijn dunne wrappers rond standaardcomponenten.
  • Platform-API-calls: Als je app platform-API's aanriep voor zaken als bestandsopslag of e-mail, vervang door directe integraties (S3, SendGrid, etc.).

Test elke vervanging individueel. Probeer niet alles tegelijk te wisselen.

Stap 6: Deploy en verifieer

Deploy je gecontaineriseerde app naar je VPS. Zet een reverse proxy op voor HTTPS:

server {
    listen 80;
    server_name jouwdomein.nl;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Loop door elke feature van je app. Vul elk formulier in. Klik op elke knop. Check elke pagina. Vergelijk het gedrag met de platformversie. Fix wat er kapot is.

Dit is ook het moment om je git-repository op te zetten als je dat nog niet hebt gedaan. Elke wijziging vanaf nu moet gecommit en gevolgd worden.

Stap 7: Werk DNS bij en ga live

Zodra je zelfgehoste versie correct werkt, verwijs je domein naar je nieuwe server:

# Verwijs je domein naar je eigen server
# Bij je DNS-provider, werk bij:
A    jouwdomein.nl    → 123.45.67.89
CNAME www             → jouwdomein.nl

Houd de platformversie nog een paar dagen draaiende als fallback. Zodra je hebt bevestigd dat alles op de nieuwe infrastructuur werkt, zeg je het platformabonnement op.

Je bezit nu je app. Geen tokens. Geen agents. Geen verrassingsfacturen.

Wanneer hulp inhuren

Je kunt deze migratie zelf doen als je vertrouwd bent met de command line en basis-deployment. Maar er zijn situaties waarin je een technisch persoon moet inschakelen:

  • De codebase heeft geen tests en je kunt niet verifiëren of het werkt. Een developer kan basale smoketests schrijven om te zorgen dat er niks breekt tijdens de migratie.
  • Je begrijpt de deployment-pipeline niet. Docker, reverse proxies, SSL-certificaten. Als dit onbekende concepten zijn, besparen een paar uur met een DevOps-engineer je dagen debuggen.
  • Het databaseschema is een puinhoop. AI-gegenereerde schema's hebben vaak overbodige tabellen, ontbrekende indexen en inconsistente naamgeving. Een developer kan dit opruimen tijdens de migratie in plaats van de schuld mee te nemen.
  • Auth, betalingen of e-mail moeten blijven werken. Deze integraties zijn kritiek en fragiel. Als het platform authenticatie afhandelde en je je eigen auth moet opzetten, haal hulp. Auth kapotmaken betekent je gebruikers buitensluiten.

De ideale inhuur is iemand die zowel AI-gegenereerde code als degelijke infrastructuur begrijpt. Ze bestaan. Ze kunnen agent-output lezen, identificeren wat bruikbaar is en de rest herstructureren. Een senior developer met AI-workflowervaring kan de meeste apps in een tot drie dagen migreren.

Preventie: zo voorkom je lock-in de volgende keer

Als je een nieuw project start met AI-tools, kun je de snelheid krijgen zonder de val. Zo doe je dat:

Bezit je git-repo vanaf dag een. Elke regel code hoort in een repository die jij beheert. GitHub, GitLab, een zelfgehoste Gitea-instantie. Maakt niet uit. Wat telt is dat je het kunt clonen, lezen en deployen zonder enig platform ertussen.

Gebruik standaard deployment. Docker op een VPS. Dat is het. Geen proprietary deployment-pipelines, geen platformspecifieke buildstappen. Als je app niet kan draaien in een Docker-container op een standaard Linux-server, zit je vast.

Eis een echte database die je beheert. Draai je eigen PostgreSQL- of MySQL-instantie. Geen platformbeheerde database die verdwijnt als je je abonnement opzegt. Je data is je bedrijf. Bezit het.

Houd AI als tool, niet als runtime. Gebruik AI om code te schrijven. Gebruik AI om te debuggen. Gebruik AI om boilerplate te genereren. Maar zodra de code geschreven is, moet het draaien op standaardinfrastructuur zonder enige AI-betrokkenheid. Je productie-app hoort niet afhankelijk te zijn van een AI-agent om te functioneren.

Zet CI/CD vroeg op. Een simpele GitHub Actions-workflow die je Docker-image bouwt en deployt bij een push. Dit kost 30 minuten om op te zetten en neemt elke verleiding weg om op een platform te leunen voor deployment.

Documenteer je architectuur. Schrijf je stackkeuzes, patronen en conventies op. Wanneer je AI gebruikt om code te genereren, voed het met deze documentatie. Dit is de Architecture First-aanpak: AI produceert dramatisch betere code wanneer het je beperkingen kent.

De conclusie

AI-platformen zijn krachtig voor prototyping. Ze comprimeren weken ontwikkeling in uren. Die waarde is echt.

Maar prototyping en productie zijn verschillende dingen. Een prototype moet werken. Een productie-app moet onderhoudbaar, draagbaar en betaalbaar zijn. AI-platformen geven je het eerste ten koste van het tweede.

Als je nu maandelijks AI-tokenkosten betaalt om je app in leven te houden, heb je opties. De migratie is niet triviaal, maar wel overzichtelijk. Exporteer, audit, containeriseer, deploy, verifieer, wissel DNS. Zeven stappen. Aan de andere kant staat een app die je bezit, draaiend op infrastructuur die je beheert, met kosten die je kunt voorspellen.

Je app hoort geen AI-agent nodig te hebben om de lichten aan te houden. Ship met AI. Draai zonder.