Een vibe coding MVP heeft één taak: ontdekken of mensen willen wat u bouwt. Vibe coding betekent software bouwen door aan een AI-tool te beschrijven wat u wilt en de code te accepteren die de tool schrijft. Daarmee test u een idee snel, ook als u zelf niet technisch bent en nog niemand heeft aangenomen. Het risico zit niet in die test. Het zit in het moment waarop de test ongemerkt het bedrijf wordt: een klant betaalt, onbekenden melden zich aan met hun persoonsgegevens, een freelancer moet de code aanpassen of een investeerder wil het product zien.
Dit artikel laat zien waar die grens ligt, wat u controleert zodra uw MVP eroverheen gaat, of u de code behoudt, versterkt of herbouwt, en welke EU-regels gelden voor een vibe-coded MVP. De basis van MVP-ontwikkeling en de volledige route naar AI-gebouwde producten veilig in productie hebben elk een eigen gids.
TL;DR
Vibe coding is een goede manier om met een MVP de vraag naar uw product te testen. Een vibe-coded MVP is geen test meer zodra mensen ervan afhankelijk worden: vanaf dan moet de code hun gegevens en geld beschermen, en moet iemand anders dan de AI-tool de code begrijpen.
- Vijf signalen markeren die overgang: een eerste betalende klant, persoonsgegevens van mensen die u niet kent, een tweede persoon die de code wijzigt, een investeerder die het product wil zien, en koppelingen met betalingen of systemen van andere bedrijven. Eén signaal betekent: voer de controles uit; twee of meer betekent: laat een onafhankelijke review doen voordat u verder groeit.
- Drie controlegroepen gaan voor: data en toegang, geldstromen, en eigenaarschap en overdracht. Data en toegang gaat voor: broken access control is A01 in de OWASP Top 10:2025.
- Behouden, versterken of herbouwen volgt uit wat de controles vinden: versterk de code als de problemen in toegangsregels, keys en foutafhandeling zitten; herbouw één onderdeel als authenticatie, betalingen of het datamodel structureel fout is.
- De AVG kent geen uitzondering voor een MVP of testfase: verwerkt een MVP persoonsgegevens binnen de reikwijdte van artikel 3, dan zijn een privacyverklaring en grondslag, verwerkersovereenkomsten volgens artikel 28 en een procedure voor een melding datalek volgens artikel 33 nodig; een chatbot voegt de transparantieplicht van artikel 50 van de EU AI Act toe, die sinds 2 augustus 2026 geldt.
Waarvoor vibe coding bij een MVP geschikt is
Vibe coding past bij een MVP die bedoeld is om te leren: wil iemand dit, melden mensen zich aan, betalen ze? Collins Dictionary koos “vibe coding” als Word of the Year 2025 en omschrijft het als AI gebruiken, aangestuurd in gewone taal, om computercode te helpen schrijven. Voor een MVP, de kleinste versie van een product die één kernaanname test bij echte gebruikers, verandert die methode wie de test kan uitvoeren: een founder die de MVP met AI bouwt, kan de kernflow beschrijven, met gebruikers uitproberen en na het eerste gesprek aanpassen.
Het voordeel is concreet. De founder beschrijft een wijziging en test die zonder op een ontwikkelteam te wachten, de investering vooraf blijft klein en niemand hoeft te worden aangenomen voordat de vraag bewezen is. Daarom is vibe coding een verstandig startpunt als de vraag is of iemand het product wil: de prijs van ongelijk hebben is dan een verworpen idee, geen verworpen codebase.
Is vibe coding dus levensvatbaar? Voor validatie wel. Als product voor de lange termijn hangt het af van drie groepen controles: data en toegang, geldstromen, en eigenaarschap en overdracht. Een AI-tool optimaliseert voor code die draait; de tool beslist niet zelf wie welk record mag zien.
De indicator is eenvoudig. Heeft uw MVP zijn validatievraag beantwoord, dan is zijn taak klaar en gaat de volgende beslissing over wat u aan klanten levert.
Een vibe-coded MVP vs een product waar klanten op rekenen
Een vibe-coded MVP moet bewijzen dat iets werkt als de founder het gebruikt. Een product waar klanten op rekenen, moet blijven werken en de gegevens van elke klant gescheiden houden als onbekenden het gebruiken op manieren die niemand heeft bedacht. Daarom is “het werkt in de demo” zwak bewijs. In een gebruikersstudie van Stanford vonden Perry et al. (ACM CCS 2023) dat deelnemers met een AI-codeassistent minder veilige code schreven dan deelnemers zonder, en vaker dachten dat hun code veilig was. De studie gebruikte een eerdere generatie assistent; het verschil dat zij mat, tussen code die af lijkt en code die veilig is, is wat tabel 1 vergelijkt.
| Onderdeel | Wat u controleert in een vibe-coded MVP | Wat klanten die erop rekenen nodig hebben |
|---|---|---|
| Inloggen en toegangsregels | Of een klant de bestelling van een andere klant kan zien door een nummer in de adresbalk te wijzigen | Elk verzoek op de server gecontroleerd op wie het doet |
| Database en persoonsgegevens | Of de toegangsregels van de database aan staan, en welke persoonsgegevens worden opgeslagen die het product niet gebruikt | Toegangsregels per gebruiker of klantaccount; alleen de gegevens die het product nodig heeft |
| Betalingen | Of een bestelling als betaald wordt gemarkeerd omdat de browser dat meldt | Betaalstatus bevestigd door de betaalprovider, op de server |
| Foutafhandeling | Wat een gebruiker ziet als een stap halverwege mislukt, en of de fout wordt gelogd | Duidelijke foutmeldingen en een log dat iemand leest |
| Tests | Of iets aanmelden, betalen en gegevenstoegang controleert na een wijziging | Geautomatiseerde tests rond de stromen met geld en persoonsgegevens |
| Release en rollback | Of een release kan worden teruggedraaid als aanmelden niet meer werkt | Een herhaalbare release en een weg terug naar de laatste werkende versie |
| Wie de code begrijpt | Of iemand anders dan de AI-tool kan uitleggen hoe aanmelden, betalen en gegevenstoegang werken | Minstens één persoon die die stromen kan uitleggen en wijzigen |
| Documentatie | Of instellingen, keys en externe diensten ergens zijn vastgelegd | Een kort overzicht van diensten, instellingen en wie eigenaar is |
Behoud de vibe-coded MVP als basis als het datamodel klopt en de toegangsregels ter plekke te herstellen zijn. Plan een herbouw van specifieke onderdelen als het datamodel of de authenticatie fout is, want elke functie die daarop wordt gebouwd, erft de fout. De beveiligingsrisico’s achter deze rijen staan in vibe coding security: risico’s bij echte gebruikers.
Vijf signalen dat uw MVP geen test meer is
Een vibe-coded MVP is geen test meer zodra iemand anders dan u ervan afhankelijk wordt. Deze vijf signalen markeren dat moment:
- De eerste betalende klant. Geld verandert de verwachting van “probeer dit” in “dit hoort te werken”, en een betaalfout kost nu iemand anders geld.
- Persoonsgegevens van mensen die u niet persoonlijk kent. Volgens artikel 4, lid 1 AVG (GDPR) is een persoonsgegeven alle informatie over een geïdentificeerde of identificeerbare persoon, dus een e-mailadres in uw gebruikerstabel telt al mee.
- Een tweede persoon moet de code wijzigen. Een developer of freelancer die niet kan volgen hoe aanmelden, betalen en gegevenstoegang werken, gaat trager werken of wijzigt dingen die hij niet begrijpt.
- Een investeerder of overnemer wil het product of de code zien. Vragen over wie de code begrijpt en hoe gegevens zijn beschermd, worden onderdeel van technical due diligence.
- Het product koppelt met betalingen, klantsystemen of gegevens van andere bedrijven. Elke koppeling voegt inloggegevens toe die u moet beschermen, en een storing die verder reikt dan uw eigen product.
Wij adviseren een eenvoudige regel. Eén signaal betekent: voer de drie controlegroepen uit, namelijk data en toegang, geldstromen, en eigenaarschap en overdracht. Twee of meer signalen betekent: laat een onafhankelijke review doen voordat u verder groeit, want dan raakt een gemist probleem tegelijk betalende klanten, hun gegevens en uw gesprekken met investeerders.
Wat u controleert voordat klanten op uw vibe-coded MVP rekenen
Drie groepen controles gaan vooraf aan het moment dat klanten op een vibe-coded MVP rekenen: data en toegang, geldstromen, en eigenaarschap en overdracht. Begin bij data en toegang. Broken access control staat op de eerste plaats, als A01, in de OWASP Top 10:2025, de referentielijst van beveiligingsrisico’s voor webapplicaties. Is uw tijd beperkt, dan sluit u deze categorie als eerste uit.
Deze controles zijn specifiek voor de MVP-fase. Voor de volledige releasecontrole gebruikt u de production readiness checklist voor AI-gebouwde producten.
Data en toegang
De controle op data en toegang beantwoordt één vraag: kan een gebruiker gegevens bereiken die niet van hem zijn? Log in als testgebruiker, open een record en wijzig daarna het ID in de adresbalk in een ID van een andere testgebruiker. Laadt het record, dan controleert de server niet wie de eigenaar is.
Slaat uw MVP gegevens op in Supabase, controleer dan of row-level security, een databaseregel die elke gebruiker beperkt tot de rijen die hij mag zien, aan staat voor elke tabel met klantgegevens. Onze gids over Supabase RLS beschrijft wat u uw developer vraagt. Controleer ook dat er geen API key met schrijf- of beheerrechten in de code staat die in de browser draait; gelekte API keys in AI-producten legt uit hoe keys lekken en hoe u dat herstelt. Maak tot slot een lijst van de persoonsgegevens die u verzamelt en schrap wat het product niet gebruikt: artikel 5, lid 1, onder c AVG eist dat gegevens beperkt blijven tot wat nodig is voor het doel.
Geldstromen
De controle op geldstromen zorgt dat een bestelling pas als betaald geldt als de betaalprovider dat bevestigt. Een webhook is een bericht dat de betaalprovider naar uw server stuurt als een betaling slaagt, mislukt of wordt terugbetaald. Uw server handelt op dat geverifieerde bericht, niet op een “gelukt”-pagina die de browser bereikt.
Drie controles dekken de MVP-fase. Ten eerste wordt de betaalstatus op de server bevestigd via de webhook van de provider, en wordt de handtekening van die webhook gecontroleerd voordat uw code hem vertrouwt. Ten tweede wijzigen terugbetalingen en mislukte betalingen de status van de bestelling en krijgt de klant bericht. Ten derde worden prijzen en kortingen op de server bepaald, zodat niemand een prijs kan verlagen door het verzoek in de browser aan te passen.
Eigenaarschap en overdracht
De controle op eigenaarschap en overdracht bevestigt dat het product kan draaien en veranderen zonder de chatgeschiedenis van de AI-tool. De code hoort in een repository, een opslag van de code en de wijzigingsgeschiedenis met versiebeheer, die van uw bedrijf is en niet alleen in het account van de AI-tool staat.
Environment variables, de instellingen en geheime keys die de app bij het opstarten leest, zijn vastgelegd: bij welke dienst ze horen en wie ze kan wijzigen. De test voor deze groep is een gesprek. Iemand anders dan de AI-tool moet kunnen uitleggen hoe aanmelden, betalen en gegevenstoegang werken. Kan niemand dat, dan begint een tweede developer met het reverse-engineeren van uw product.
Uw vibe-coded MVP behouden, versterken of herbouwen
Wat de drie controlegroepen vinden, bepaalt of u een vibe-coded MVP behoudt, versterkt of herbouwt; de manier waarop de code is geschreven niet. Standaard herbouwen gooit productbeslissingen weg die uw gebruikers al hebben gevalideerd, van de flows die zij begrijpen tot de gegevens die u hebt leren verzamelen.
| Wat de controles vinden | Advies | Voorwaarde |
|---|---|---|
| Oplosbare problemen in toegangsregels, blootgestelde keys en foutafhandeling | Behouden en versterken | Het datamodel kan de volgende functies aan en de fixes blijven binnen bestaande onderdelen |
| Eén onderdeel structureel fout, zoals authenticatie of betalingen | Dat onderdeel herbouwen | De rest van de codebase doorstaat de controles en kan het nieuwe onderdeel netjes aanroepen |
| Een datamodel dat de volgende functies niet aankan | Meer herbouwen, te beginnen bij het datamodel | De gevalideerde flows en schermen blijven de specificatie voor de herbouw |
Versterken betekent de problemen ter plekke oplossen en tests toevoegen rond de stromen met geld en persoonsgegevens, zodat de fixes blijven werken. De volledige afweging tussen refactoren of herbouwen voor een AI-gebouwde app heeft een eigen gids, inclusief de signalen die op herbouw wijzen.
Twijfelt u tussen behouden, versterken of herbouwen? Een AI-built product review van uw vibe-coded MVP scheidt wat betalende klanten nu in de weg staat van wat kan wachten, en geeft uw team een duidelijke volgorde voor de fixes. Vraag een product review aan
Wat de kosten van de volgende fase bepaalt
De kosten om van een vibe-coded MVP een product te maken waar klanten op rekenen, hangen af van zes factoren. De eerste twee volgen direct uit wat de controles vinden:
- Het aantal en de diepte van de gevonden fixes. Een paar kleine fixes in toegangsregels kosten minder dan één structureel probleem in de authenticatie.
- Of het datamodel verandert. Een wijziging in het datamodel raakt elke functie die die gegevens leest of schrijft.
- De complexiteit van betalingen en koppelingen. Elke betaalmethode, elk klantsysteem en elke partnerkoppeling voegt werk en tests toe.
- Gebruikskosten van AI-modellen en API’s. Roept het product tijdens gebruik een AI-model aan, dan groeien de gebruiksafhankelijke kosten mee met het aantal gebruikers.
- Hosting en monitoring. Een product waar klanten op rekenen, heeft logs, alerts en back-ups nodig die de MVP misschien niet heeft.
- Wie het onderhoudt. Een interne developer, een freelancer en een extern team brengen elk andere doorlopende kosten mee.
Voor uw begroting scheidt onze gids over de kosten van een AI-app bouwkosten van gebruikskosten. De prijs van een review of fixes hangt af van de scope; Sunbytes adviseert daarover per situatie.
Welke EU-regels gelden voor een vibe-coded MVP
De AVG (GDPR) geldt voor een vibe-coded MVP zodra de MVP persoonsgegevens verwerkt binnen de territoriale reikwijdte van artikel 3 AVG: als uw bedrijf in de EU gevestigd is en de gegevens verwerkt in het kader van die vestiging, of, voor een bedrijf buiten de EU, als de MVP goederen of diensten aanbiedt aan mensen in de EU of hun gedrag daar volgt. Dat kan al tijdens de testfase het geval zijn. Of de gebruikers testers, bekenden of betalende klanten zijn, bepaalt niet of de AVG geldt, en er is geen uitzondering voor MVP’s of start-ups. De omvang van de organisatie verandert enkele plichten, zoals de voorwaardelijke uitzondering op het verwerkingsregister in artikel 30, lid 5 voor organisaties met minder dan 250 medewerkers, maar niet de vier die in de MVP-fase het zwaarst wegen:
- Een privacyverklaring en een grondslag. Artikel 13 bepaalt wat gebruikers te horen krijgen; artikel 6 noemt de grondslagen.
- Verwerkersovereenkomsten. Verwerkt een database-, hosting- of AI-modelprovider persoonsgegevens in uw opdracht, dan eist artikel 28 een overeenkomst met die partij. Stel de rol van elke provider en de overeenkomst vast voordat echte gebruikers zich aanmelden.
- Een procedure voor een melding datalek. Volgens artikel 33 AVG meldt de verwerkingsverantwoordelijke een datalek zonder onredelijke vertraging en, waar mogelijk, uiterlijk 72 uur nadat hij ervan kennis heeft genomen aan de bevoegde toezichthoudende autoriteit, tenzij het datalek waarschijnlijk geen risico oplevert voor de rechten en vrijheden van mensen. Een melding na 72 uur moet de redenen voor de vertraging vermelden. Voor een start-up met haar enige of hoofdvestiging in Nederland is dat normaal gesproken de Autoriteit Persoonsgegevens.
- Toestemming voor cookies. Voor een website of app gericht op Nederlandse gebruikers zegt de ACM over het plaatsen van cookies dat tracking cookies en privacygevoelige analytische cookies toestemming vereisen. Functionele cookies en analytische cookies met weinig gevolgen voor de privacy van bezoekers mag u zonder toestemming plaatsen, als u bezoekers vertelt dat u ze gebruikt.
Bevat uw MVP een chatbot die met gebruikers praat, dan geldt sinds 2 augustus 2026 artikel 50, lid 1 van de EU AI Act: de aanbieder van het AI-systeem moet het zo ontwerpen dat gebruikers weten dat zij met AI communiceren, tenzij dat voor een redelijk geïnformeerde persoon in de context duidelijk is. Of uw start-up de aanbieder is, hangt af van hoe de chatbot is gebouwd en aangeboden; laat die rol juridisch beoordelen.
Hoe Sunbytes vibe-coded MVP’s reviewt
Of uw MVP met vibe coding is gebouwd, doet er minder toe dan of hij klaar is voor de klanten die er nu op rekenen. Een AI-built product review van Sunbytes beantwoordt die vraag op hetzelfde terrein als de drie controlegroepen: wie welke gegevens kan bereiken, hoe geld beweegt en of iemand anders dan de AI-tool het product kan draaien.
Software engineers en securityspecialisten van Sunbytes reviewen hetzelfde product: de code, architectuur, beveiliging, betrouwbaarheid en deployment. Aan de securitykant gaat het om authenticatie, rechten, toegang tussen gebruikers, blootgestelde geheimen, databaseregels en gevoelige gegevensstromen. Omdat beide disciplines naar één codebase kijken, gaan de bevindingen verder dan een geautomatiseerde scan. Elke bevinding komt met het bewijs erbij, in een plan voor wat u nu oplost, wat kan wachten en waar u begint.
De review gaat niet uit van een herbouw: uw eigen team kan de fixes doen, of engineers van Sunbytes lossen de prioriteiten op en controleren ze opnieuw. Toegang tot uw code en gegevens valt onder het ISO 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes, met delivery onder Nederlandse leiding en 15+ jaar en 300+ projecten in softwareontwikkeling achter de aanpak.
Vertoont uw MVP twee of meer van de vijf signalen, bespreek dan een AI-built product review met ons
