Een vibe-coded app productieklaar maken

De demo werkt. Productie is een ander vak.

Je beschreef een app aan Lovable, Cursor of Bolt, en een paar uur later had je iets dat draait. Pagina’s, een login, een database, een werkende flow. Het demot prachtig. Dus je zet er echte gebruikers op, en daar begint de ellende.

De reden is saai en voorspelbaar: AI schrijft code die werkt, nog voordat het code schrijft die veilig is. Security, foutafhandeling en toegangscontrole zijn onzichtbaar in een demo, dus slaat het model ze standaard over. De tools doen precies waarvoor ze gemaakt zijn, en in een demo komt de code die echte gebruikers beschermt gewoon nooit aan bod. In Veracode’s analyse van AI-gegenereerde code uit 2025 bevatte 45% minstens één kwetsbaarheid uit de OWASP Top 10, en onafhankelijke studies leggen de kwetsbaarheidsdichtheid op ongeveer 2,7 keer die van handgeschreven code.

We schreven eerder over waarom vibe-coded projecten vastlopen in de laatste 20% van een vibe-coded project. Dit is de andere helft: wat je er concreet aan doet, in de volgorde die telt.

Begin met uitzoeken wat de AI eigenlijk gebouwd heeft

Je kunt geen code beveiligen die je niet begrijpt. Voordat je een regel aanpast, maak een eerlijke inventarisatie van wat er onder de motorkap zit, want vibe coding verbergt die keuzes voor je terwijl je bouwt.

Een middag lezen voordat je iets aanraakt bespaart je hetzelfde probleem drie keer oplossen.

De beveiligingsgaten eerst, en in deze volgorde

Niet elk gat is even gevaarlijk. Fix de dingen waarmee je vandaag gehackt wordt vóór de dingen die je volgende maand vertragen. Dit is de volgorde waarin wij werken.

Maak het dan bestand tegen echte gebruikers

Zodra het veilig is, maak het robuust. Het happy path werkt altijd. Productie is alles wat gebeurt als de invoer fout is, het netwerk wegvalt of een dienst plat ligt.

Leg een vangnet voordat je iets verandert

Vibe-coded projecten hebben bijna nooit tests, waardoor elke latere aanpassing, door jou of door de volgende AI-prompt, een gok is dat er niets anders sneuvelt. Voordat je verder bouwt, schrijf tests rond de paden die je je niet kunt veroorloven te breken: login, betalingen, alles wat data wegschrijft. Dat is wat je in staat stelt snel te blijven bewegen zonder telkens productie om te leggen.

Deploy alsof het echt is

Het gat tussen een preview-URL en een product is een handvol onglamoureuze stappen die vibe coding volledig overslaat.

Weet wanneer je stopt met pleisters plakken en hulp haalt

Een deel hiervan kun je zelf, met dezelfde AI-tools die de app bouwden, zolang je weet wat je moet vragen. Maar er is een punt waarop pleisters plakken niet meer helpt: als de authenticatie niet bij de architectuur past, als de database-structuur niet gaat schalen, als een betaalintegratie betekent dat je moet uitpluizen hoe de hele backend is opgezet. Dat zijn ontwerpbeslissingen, en geen enkele prompt lost een ontwerpbeslissing netjes op.

Dat is het moment waarop een review zichzelf terugverdient. Een vibe coding audit vertelt je precies welke van bovenstaande stappen je app mist en hoe diep de fixes gaan, voordat je een maand aan de verkeerde besteedt. En wil je het verstevigen en hosten liever overlaten aan een team dat dit dagelijks doet, dan is dat managed development: jij blijft tweaken in Cursor terwijl wij de productiekant overeind houden.

Conclusie: je verstevigt, je herbouwt niet

De fout die teams maken is een vibe-coded MVP behandelen als af of als waardeloos. Het is geen van beide. Het bewees het idee sneller dan welk traditioneel proces dan ook had gekund, en dat is echt waardevol. Productieklaar maken is de tweede helft van het werk, en dat is een andere helft.

Werk de lijst van boven naar beneden af, fix eerst de gehackt-word-je-vandaag-items, en je maakt van een veelbelovend prototype iets dat je met een gerust hart voor betalende klanten kunt zetten, zonder de snelheid te verliezen die je hier bracht.