Van prototype naar productie: waarom vibe-coded apps vaak stranden

Een vibe-coded prototype is pas klaar voor productie wanneer het niet alleen de gewenste taak uitvoert, maar ook gegevens afschermt, fouten beheerst, wijzigingen doorstaat en kan worden hersteld. Het verschil zit meestal niet in een mooier scherm, maar in het werk dat je tijdens een demo nauwelijks ziet: toegangscontrole, datakwaliteit, tests, koppelingen en dagelijks beheer.

Bij vibe coding beschrijf je wat een applicatie moet doen en laat je AI code genereren en aanpassen. Daarmee kun je snel een idee tastbaar maken. Maar een succesvolle demonstratie met één account en voorbeeldgegevens bewijst niet dat klanten er veilig op kunnen vertrouwen. Dat geldt overigens ook voor traditioneel ontwikkelde software.

Met ‘vaak stranden’ bedoelen we in dit artikel herkenbare knelpunten op weg naar productie, niet een gemeten uitvalpercentage: de bronnen hieronder geven geen betrouwbaar percentage mislukte vibe-coded apps. We bekijken waarom die overgang lastig kan zijn en hoe je als MKB-ondernemer voorkomt dat een bruikbaar idee blijft hangen in de demo.

Wat is het verschil tussen een prototype, een MVP en productie?

Een prototype beantwoordt vooral de vraag: werkt dit idee voor de gebruiker? Een MVP is de kleinste bruikbare versie waarmee je de waarde in de praktijk toetst. Productie betekent dat echte gebruikers voor hun werk op de applicatie vertrouwen. Ook een kleine MVP kan in productie draaien; ‘minimaal’ mag dan slaan op het aantal functies, niet op noodzakelijke beveiliging.

Onderdeel	Prototype	Productieapplicatie
Gegevens	Fictieve of beperkte testgegevens	Echte gegevens met afspraken over toegang, kwaliteit en bewaartermijnen
Gebruikers	Eén tester of een begeleide groep	Meerdere gebruikers met geteste rollen en rechten
Fouten	Handmatig oplossen tijdens de demo	Duidelijke meldingen, logging en een verantwoordelijke voor opvolging
Wijzigingen	Direct aanpassen en opnieuw proberen	Testen, beoordelen en gecontroleerd vrijgeven
Herstel	Opnieuw beginnen kan acceptabel zijn	Back-ups en een beproefd herstelplan
Eigenaarschap	De maker weet hoe het werkt	Accounts, documentatie en beheer zijn overdraagbaar

Twijfel je nog over het type oplossing? Begin bij de beslisboom voor een website of webapplicatie. Een informatieve website vraagt andere controles dan een portaal met klantdocumenten of een tool die prijzen berekent.

Zeven redenen waarom een vibe-coded app bij de demo blijft hangen

1. De demo test alleen het ideale scenario

Een gebruiker vult geldige gegevens in, de koppeling reageert direct en het resultaat ziet er goed uit. In productie zijn invoervelden leeg, bestanden te groot, sessies verlopen en externe systemen tijdelijk onbereikbaar. Een app die alleen de ideale route doorstaat, kan op dat moment onbruikbaar worden.

Wat je doet: beschrijf naast de normale handeling ook foutgevallen. Wat gebeurt er bij een dubbele aanvraag, een time-out of een gebruiker die tweemaal op verzenden klikt? Leg vast welke melding verschijnt en of er toch iets wordt opgeslagen.

2. Een login wordt verward met echte toegangsbeveiliging

Dat een gebruiker moet inloggen, zegt nog niet welke gegevens die daarna kan bekijken. Een verborgen beheerknop verhindert bijvoorbeeld niet automatisch dat iemand rechtstreeks een verzoek naar de applicatie stuurt. Rechten moeten aan de serverkant en waar passend in de database worden afgedwongen, niet alleen in het scherm.

Wat je doet: test met twee verschillende klantaccounts en een beheerdersaccount. Laat controleren dat klant A geen documenten, aanvragen of gegevens van klant B kan lezen of wijzigen, ook niet via een aangepaste URL of rechtstreeks verzoek. Laat dergelijke controles binnen een afgesproken testomgeving uitvoeren. Gebruik OWASP ASVS als kader voor concrete beveiligingseisen; een afgeronde checklist is geen garantie dat elke kwetsbaarheid weg is.

3. Prompts vervangen een samenhangend gegevensmodel

Een extra veld, nog een filter en een tweede dashboard zijn snel toegevoegd. Zonder gezamenlijk ontwerp ontstaan verschillende definities van ‘klant’, ‘order’ of ‘goedgekeurde offerte’. Gegevens worden dubbel opgeslagen of veranderen op het ene scherm wel en op het andere niet.

Wat je doet: bepaal welke bron leidend is, welke gegevens verplicht zijn en welke relaties uniek moeten blijven. Test gelijktijdige wijzigingen en bepaal hoe je conflicten oplost. Bij complexere informatievragen kan AI en data: datasets structureren en toegankelijk maken helpen om eerst de basis op orde te brengen.

4. Elke snelle reparatie maakt de volgende wijziging moeilijker

Technische schuld ontstaat wanneer tijdelijke oplossingen later extra werk veroorzaken. Bij AI-ondersteund ontwikkelen kan dat gebeuren als je steeds nieuwe instructies geeft zonder te controleren hoe de wijziging in het bestaande geheel past. Vergelijkbare controles worden dan bijvoorbeeld op verschillende plaatsen anders uitgevoerd.

Wat je doet: laat de belangrijke onderdelen beoordelen, bundel terugkerende regels op een consistente plek en houd vast aan een beperkt aantal duidelijke patronen. Vraag bij elke reparatie niet alleen ‘werkt dit nu?’, maar ook ‘blijven de andere gebruikersroutes werken?’. Soms is een onderdeel herschrijven verstandiger dan een volgende laag uitzonderingen toevoegen.

5. Koppelingen en AI-kosten zijn niet doorgerekend

Een koppeling met CRM, boekhouding of een AI-model werkt tijdens de demo met weinig verzoeken. Later krijg je te maken met gebruikslimieten, vertraging, veranderde toegang en kosten per verzoek. Herhaalde pogingen kunnen bovendien dubbele gegevens of extra kosten opleveren.

Wat je doet: leg per koppeling vast wie eigenaar is, welke limieten gelden en wat de app doet bij uitval. Houd geheime API-sleutels buiten browsercode en voorkom dat ze in logboeken of foutmeldingen terechtkomen. Stel waar mogelijk gebruikslimieten en meldingen in. Een browserknop uitschakelen is geen afdoende bescherming tegen ongewenst API-gebruik.

6. Back-ups bestaan, maar herstel is nooit geprobeerd

Een codeversie terugzetten herstelt niet automatisch verwijderde klantgegevens. Een databaseback-up bevat ook niet per definitie geüploade documenten. Bovendien kunnen de teruggezette gegevensstructuur en de huidige applicatiecode van elkaar verschillen.

Wat je doet: inventariseer afzonderlijk code, database, bestanden en configuratie. Spreek af hoeveel gegevensverlies en uitvaltijd acceptabel zijn en oefen het herstel in een aparte omgeving. De Lovable-documentatie over databaseback-ups benoemt expliciet dat database-export en -herstel geen bestanden in opslag bevatten; controleer de beschikbare mogelijkheden voor jouw project.

7. Niemand is verantwoordelijk na de oplevering

Een applicatie is geen eenmalig bestand. Gebruikers melden fouten, leveranciers wijzigen hun diensten en afhankelijkheden hebben onderhoud nodig. Een logscherm zonder iemand die de meldingen opvolgt, is nog geen operationeel beheer.

Wat je doet: wijs een eigenaar aan voor incidenten, updates en gebruikersvragen. Maak afspraken over bereikbaarheid, prioriteiten, toegang tot accounts en onderhoudsbudget. Spreek af welke signalen actief worden bewaakt; beschikbare logs betekenen niet automatisch dat je een waarschuwing ontvangt.

Praktische productiechecklist voor MKB-ondernemers

Vraag vóór livegang per onderdeel om bewijs, een eigenaar en een besluit. De volgende checklist is een praktisch vertrekpunt, geen certificering of volledige beveiligingsaudit. Bij betalingen, gevoelige gegevens of bedrijfskritische processen is aanvullend specialistisch onderzoek nodig.

Controle	Bewijs dat je wilt zien	Wie je erbij betrekt
Kernproces	Een complete handeling van invoer tot opgeslagen en teruggelezen resultaat	Proceseigenaar en tester
Rollen en rechten	Tests met verschillende accounts, inclusief geweigerde toegang	Ontwikkelaar of beveiligingsspecialist
Gegevenskwaliteit	Controles op duplicaten, verplichte velden en gelijktijdige wijzigingen	Data-eigenaar en ontwikkelaar
Geheime sleutels	Controle dat sleutels niet in browsercode, responses of logs staan	Technisch beheerder
Koppelingen	Gedrag bij time-outs, limieten, verlopen toegang en dubbele verzoeken	Koppelingseigenaar
Prestaties	Een test met representatieve gegevens en verwachte gelijktijdige gebruikers	Ontwikkelaar en opdrachtgever
Back-up en herstel	Een geslaagde hersteloefening voor gegevens en bestanden	Technisch beheerder
Privacy	Doel, toegang, bewaartermijn en afspraken met betrokken verwerkers	Privacyverantwoordelijke
Release en beheer	Testuitslag, terugvalplan, foutopvolging en accountoverdracht	Producteigenaar en beheerder

Gebruik bij de formele overdracht ook onze acceptatiechecklist voor websites en webapplicaties. Daarmee vertaal je technische controles naar afspraken die je als opdrachtgever kunt beoordelen.

Fictief voorbeeld: van offertetool naar betrouwbaar klantportaal

Het volgende voorbeeld is verzonnen om de aanpak uit te leggen; het is geen klantcase of gemeten resultaat. Een installatiebedrijf bouwt met AI een offertetool. Een medewerker selecteert werkzaamheden, de tool berekent een bedrag en maakt een document. Met voorbeeldgegevens werkt de demo goed. Het bedrijf wil vervolgens klanten laten inloggen en de offerte laten accepteren.

Die uitbreiding verandert het risicoprofiel. Nu moet het systeem onder meer klanten van elkaar scheiden, prijsafspraken correct toepassen en bewaren welke offerteversie is geaccepteerd. Alleen een inlogscherm toevoegen is dus onvoldoende.

1. Prijsregels vastleggen: de verantwoordelijke medewerker bepaalt welke gegevens leidend zijn voor tarieven, belasting en uitzonderingen. De regels worden met concrete testgevallen gecontroleerd.
2. Klantgegevens afschermen: twee testklanten mogen uitsluitend hun eigen offertes lezen. Onbevoegde pogingen moeten worden geweigerd.
3. Offerteversies bewaren: een wijziging in de prijslijst mag niet stilzwijgend een al geaccepteerde offerte herschrijven.
4. Dubbele handelingen beheersen: tweemaal op accepteren klikken mag niet twee orders opleveren.
5. Uitval opvangen: als de CRM-koppeling niet reageert, blijft duidelijk of de aanvraag is vastgelegd en wat nog moet gebeuren.
6. Herstel en beheer regelen: offertegegevens én documenten vallen onder het herstelplan, met een aangewezen verantwoordelijke.

Het oorspronkelijke prototype hoeft niet weg. Het blijft de basis voor het scherm en het proces, terwijl de kritieke onderdelen extra worden onderzocht en aangepast. De logische volgende stap is een beperkte pilot met afgesproken deelnemers, niet meteen toegang voor alle klanten.

In zes stappen van prototype naar productie

1. Bepaal het gebruik en het risico. Noteer wie de app gebruikt, welke gegevens erin staan en wat er gebeurt als een berekening, toegang of koppeling fout gaat.
2. Beperk de eerste versie. Kies één compleet kernproces. Zet niet-geteste functies uit en gebruik geen echte persoonsgegevens in een onbeveiligde demo.
3. Laat de technische basis beoordelen. Controleer rechten, gegevensmodel, belangrijke regels, sleutels en afhankelijkheden. Maak onderscheid tussen noodzakelijke verbeteringen en wensen.
4. Test in een aparte omgeving. Doorloop normale én afwijkende situaties met representatieve gegevens. Test herstel en houd de testomgeving gescheiden van productie.
5. Draai een gecontroleerde pilot. Spreek af wie toegang krijgt, hoe fouten worden gemeld, welke gegevens worden gebruikt en wanneer je stopt of terugvalt.
6. Geef gecontroleerd vrij en organiseer beheer. Leg testbewijs, resterende risico’s, onderhoud en eigenaarschap vast. Controleer na livegang of de belangrijkste handelingen nog werken.

De NIST Secure Software Development Framework ondersteunt het principe dat beveiliging in het ontwikkelproces hoort, niet als losse eindcontrole. Je hoeft als ondernemer niet elk technisch detail zelf uit te voeren, maar wel te weten wie ervoor verantwoordelijk is.

Zelf verder bouwen, laten verbeteren of opnieuw beginnen?

Zelf verder bouwen past bij een overzichtelijke toepassing met beperkte gevolgen bij fouten, zolang je de noodzakelijke controles kunt laten uitvoeren. Gericht laten verbeteren is passend wanneer het kernproces waarde heeft, maar rechten, data of beheer onvoldoende zijn uitgewerkt. Een onderdeel opnieuw bouwen kan nodig zijn als de basis zo onsamenhangend is dat elke wijziging elders problemen veroorzaakt.

Laat die keuze onderbouwen met bevindingen. Niet iedere AI-gegenereerde app moet opnieuw worden gebouwd, en een traditionele bouwmethode neemt risico’s niet vanzelf weg. Vraag om een plan met prioriteiten: wat blokkeert livegang, wat is nodig vóór uitbreiding en wat kan later?

Neem ook terugkerende kosten mee: hosting, koppelingen, AI-verbruik, onderhoud en incidentafhandeling. Onze MKB-begroting voor een website of webapplicatie helpt om verder te kijken dan alleen de eerste bouwprijs.

Wat betekent dit voor SEO en GEO?

Bij een openbare website horen bereikbare pagina’s, unieke metadata, interne links, correcte redirects en controle op indexering bij de productiecheck. Gestructureerde gegevens moeten aansluiten op zichtbare inhoud. Bij een afgeschermd klantportaal is het doel juist dat privégegevens niet publiek toegankelijk of indexeerbaar zijn; robots.txt en een noindex-tag vervangen geen toegangsbeveiliging.

Een duidelijke publieke uitlegpagina kan bezoekers én AI-zoekmachines helpen begrijpen wat je oplossing doet. Dat maakt vermelding in AI-antwoorden niet gegarandeerd. Houd vertrouwelijke schermen en klantgegevens buiten publieke demonstraties. Lees meer over een website bouwen met AI of gebruik onze GEO- en SEO-scan voor de openbare website.

Conclusie: maak de demo betrouwbaar, niet alleen indrukwekkend

De stap van prototype naar productie draait om aantoonbaar gedrag onder echte omstandigheden. Vibe coding kan de eerste versie versnellen, maar neemt de verantwoordelijkheid voor beveiliging, gegevens en beheer niet weg. Beperk de scope, controleer de kritieke onderdelen en maak herstel en eigenaarschap onderdeel van de oplevering.

Wil je een bestaand prototype laten beoordelen? Bekijk onze dienst vibe coding of webapplicatie laten maken. Begin met een korte beschrijving van het kernproces, de gebruikers en de gegevens die de applicatie verwerkt.

Veelgestelde vragen over vibe-coded apps in productie

Kan een vibe-coded app in productie worden gebruikt?

Ja, mits de applicatie voldoet aan de eisen van het daadwerkelijke gebruik. De bouwmethode alleen bepaalt niet of een app betrouwbaar is. Controleer onder meer toegang, dataverwerking, foutafhandeling, koppelingen, herstel en beheer.

Waarom is een werkende demo niet voldoende?

Een demo laat meestal één succesvol scenario met beperkte gegevens zien. In productie moet de app ook reageren op foutieve invoer, meerdere gebruikers, uitval en ongeoorloofde toegang. Daarvoor zijn aanvullende tests en beheerafspraken nodig.

Moet alle AI-gegenereerde code opnieuw worden geschreven?

Nee. Laat eerst onderzoeken welke onderdelen goed werken en waar risico’s zitten. Soms volstaan gerichte verbeteringen; soms is het verstandiger een kritisch onderdeel opnieuw op te zetten. Baseer die keuze op concrete bevindingen.

Is een app met een login automatisch veilig?

Nee. Inloggen stelt vast wie iemand is, maar toegangsregels bepalen welke gegevens die persoon mag lezen of wijzigen. Deze regels moeten buiten het scherm worden afgedwongen en met verschillende accounts worden getest.

Wat kost het om een prototype productierijp te maken?

Dat hangt af van het huidige ontwerp, de gegevens, de koppelingen en de gevolgen van fouten. Vraag eerst een beoordeling met concrete verbeterpunten en laat de uitvoering apart begroten. Neem ook terugkerende kosten voor gebruik en onderhoud mee.

Wat moet ik regelen voordat echte klanten toegang krijgen?

Test het kernproces en de rechten, maak privacyafspraken, controleer koppelingen en oefen herstel. Wijs een eigenaar aan voor fouten en onderhoud. Begin vervolgens met een beperkte pilot en vooraf afgesproken criteria voor uitbreiding.

Welke back-ups heeft een productieapplicatie nodig?

Inventariseer code, database, bestanden en configuratie afzonderlijk. Controleer wat de gekozen back-up werkelijk bevat en oefen herstel. Een databaseback-up bevat niet automatisch uploads en een codeversie herstellen zet niet automatisch gegevens terug.

Bronnen en verder lezen

Deze primaire bronnen onderbouwen de beveiligings- en beheerprincipes in dit artikel. Ze geven geen percentage mislukte vibe-coded projecten. Productfuncties en beschikbaarheid kunnen per platform en project verschillen.

• OWASP Application Security Verification Standard — kader voor toetsbare applicatiebeveiliging.
• NIST SP 800-218: Secure Software Development Framework — beveiliging als onderdeel van het ontwikkelproces.
• Lovable: security best practices — server-side controles, toegangsbeveiliging en veilige omgang met sleutels.
• Lovable: databaseback-ups, herstel en export — reikwijdte en aandachtspunten bij herstel.
• Lovable: logs — beschikbare informatie voor foutonderzoek en beheer.