Je app is met AI gebouwd en loopt nu vast. Wat nu?

14 oktober 2026 · 5 min leestijd · Sjoerd Visser

Het begon zo mooi. Met Lovable, Bolt, Cursor, Claude Code, Codex of ChatGPT had je in een paar avonden een werkende app. Je beschreef wat je wilde, de AI schreef de code. Vibe coding heet dat. Iets waar je een paar jaar geleden duizenden euro's en maanden voor kwijt was.

En toen kwamen de aanpassingen.

Je vraagt de AI om een kleine wijziging, en ineens werkt het inloggen niet meer. Je laat hem dat oplossen, en nu klopt de berekening op een ander scherm niet. Elke fix maakt iets anders kapot. Je durft er eigenlijk niet meer aan te komen.

Herkenbaar? Dan ben je niet de enige. Een app gebouwd met AI die niet meer werkt zoals het hoort, is geen uitzondering. En goed nieuws: het is bijna altijd op te lossen.

Vibe coding is niet het probleem

Laat ik vooropstellen: ik bouw zelf ook elke dag software met AI, vooral met Claude Code. Het is een fantastisch hulpmiddel. Het probleem is niet dát je met vibe coding je app hebt gebouwd.

Het probleem is dat AI doet wat je vraagt, en niet wat je nodig hebt.

Een ervaren ontwikkelaar denkt bij elke wijziging na over de rest van de app. Waar wordt dit nog meer gebruikt? Wat gebeurt er als er straks duizend gebruikers zijn? Wie mag deze gegevens zien? AI kijkt vooral naar de vraag van dat moment. Prompt na prompt groeit er zo een app die van buiten werkt, maar van binnen een doolhof is.

6 signalen dat je app vastloopt

Elke fix breekt iets anders. Het duidelijkste signaal. De onderdelen van je app hangen op een onlogische manier aan elkaar.
De AI gaat in rondjes. Hij lost een fout op, introduceert een nieuwe, en komt dan weer bij de eerste uit.
Je weet niet meer wat waar staat. Dezelfde logica staat op vijf plekken, net een beetje anders.
Het wordt traag. Met tien testgebruikers ging het prima, met echte klanten niet meer.
Je hebt geen idee of het veilig is. Je weet niet precies wie welke gegevens kan zien, of waar je wachtwoorden en sleutels staan.
Er is geen weg terug. Er is geen versiebeheer of back-up. Als het misgaat, weet je niet hoe het gisteren nog werkte.

Herken je er twee of meer? Lees dan vooral verder.

Het grootste risico zie je niet

Fouten die je ziet, zijn vervelend. Fouten die je niet ziet, zijn gevaarlijk.

Bij apps die met AI gebouwd zijn, duiken steeds dezelfde beveiligingsproblemen op:

Sleutels in de code. Wachtwoorden of API-sleutels die zo in de app staan, leesbaar voor iedereen die even in de browser kijkt.
Een database die openstaat. Bijvoorbeeld bij Supabase of Firebase: zonder de juiste regels kan iedere gebruiker de gegevens van alle andere gebruikers opvragen.
Controle alleen aan de voorkant. Het scherm laat een knop niet zien, maar wie de app een beetje kent, kan de actie er toch omheen uitvoeren.

Dat geldt voor elke tool, van Lovable tot Claude Code en Codex. Hoe slimmer de tool, hoe overtuigender de code eruitziet, en hoe minder je geneigd bent om het te controleren.

Je app werkt dan prima. Tot iemand het ontdekt. Werk je met gegevens van klanten, dan ben je daar ook verantwoordelijk voor, en een datalek moet je melden bij de Autoriteit Persoonsgegevens.

Wat je nu zelf kunt doen

Het voelt logisch om de AI te vragen het probleem op te lossen. Maar als je app al vastloopt, maakt elke nieuwe prompt het doolhof vaak groter. Even pauzeren is nu verstandiger dan doorbouwen.

2. Zorg voor een veilig punt

Zet je code in versiebeheer, bijvoorbeeld op GitHub, en maak een back-up van je database. Dan kun je altijd terug naar een versie die werkt, wat er ook gebeurt.

3. Controleer eerst de veiligheid

Staan er sleutels of wachtwoorden in je code? Kan een gebruiker gegevens van een andere gebruiker zien? Twijfel je, laat het dan eerst controleren. Dit gaat vóór elke nieuwe functie.

4. Schrijf op wat de app moet doen

Niet hoe hij het nu doet, maar wat hij moet doen. Welke schermen zijn echt nodig? Wat moet er absoluut goed gaan? Dat lijstje is goud waard, voor jezelf en voor iedereen die je later helpt.

Opknappen of opnieuw bouwen?

Dat is meestal de grote vraag. Het eerlijke antwoord: dat hangt ervan af.

Opknappen ligt voor de hand als:

de basis (de database en de structuur) redelijk logisch in elkaar zit;
de problemen vooral in een paar onderdelen zitten;
de app al gebruikt wordt en je niet opnieuw wilt beginnen met je gebruikers.

Opnieuw bouwen is slimmer als:

de database niet past bij wat de app moet doen;
er geen duidelijke structuur te vinden is;
opknappen meer tijd kost dan opnieuw beginnen.

Opnieuw bouwen klinkt als weggegooid geld, maar dat is het zelden. Je weet nu precies wat je app moet doen, en wat níet werkt. Je eerste versie was een prima prototype. En omdat ik zelf ook met AI bouw, gaat een nieuwe, stevige versie een stuk sneller dan je misschien denkt.

Laat iemand meekijken

Je hoeft dit niet alleen uit te zoeken. Bij een Code-check duik ik in de code van je app en vertel ik je eerlijk hoe het ervoor staat:

wat er goed is en wat niet;
waar de risico's zitten, met de veiligheid voorop;
of opknappen kan, of dat opnieuw beginnen slimmer is.

Je krijgt een helder advies, in gewone taal, voor een vaste prijs van €895 (exclusief btw). Kies je daarna voor een vervolgopdracht, dan verreken ik dat bedrag.

Liever eerst even sparren? Plan een gratis kennismaking van 30 minuten. Vertel me waar je tegenaan loopt, dan kijken we samen wat de beste volgende stap is.

Plan een Code-check Gratis kennismaking