Vibe-coding: de democratisering van software-bouw
Een paar jaar geleden moest je programmeren kunnen om software te maken. Nu typ je "maak een app waar klanten hun factuur kunnen downloaden" en binnen een kwartier staat er iets werkends online. Platforms als Lovable, Bolt.new, v0, Replit, Retool, Base44 en Rocket.new maken software-bouw toegankelijk voor bijna iedereen. Dat is een grote verandering — en wij vinden het geweldig.
Wij zien vibe-coding niet als bedreiging. Het is een uitstekende manier om:
- Binnen een dag te testen of je idee aanslaat bij klanten
- Intern een tool te bouwen die werk makkelijker maakt zonder wachten op een IT-afdeling
- Je wensen helder te krijgen vóór je met een professionele bouwer praat
- De drempel te verlagen voor niet-technische founders en medewerkers
Zie je vibe-coding project als je MVP. Het is sneller dan elke andere manier om iets tastbaars te maken. Wat je er vervolgens mee doet, bepaalt of het ook een goede basis is voor een echt bedrijf.
Maar: vier risico's waar je bewust van moet zijn
Voor een losse test of intern experiment zijn deze risico's meestal geen probleem. Maar zodra er betalende klanten, gevoelige data of een omzetafhankelijkheid ontstaat, spelen ze ineens wél. Hieronder de vier belangrijkste — in volgorde van impact.
1. Vastzitten aan je platform (vendor lock-in)
Dit is veruit het grootste risico. Je code, je database, je inlogsysteem, je vormgeving en je manier van online zetten zitten allemaal verweven met het platform. De code "downloaden" kan vaak wel, maar wat je krijgt draait niet zomaar ergens anders. Er zitten allerlei platform-specifieke dingen in die je zelf moet vervangen — en hoe groter je app wordt, hoe duurder die vervangoperatie.
Stel: je betaalt €60 per maand aan Lovable. Lijkt meevallen. Maar je hebt nu 5000 klanten. Lovable besluit de prijs te verdubbelen of iets heel anders te gaan doen. Je zit met een app die niet elders kan draaien zonder forse herbouw — en je business hangt eraan. Nu overstappen kost misschien €5000. Over twee jaar €50.000 of meer.
2. Europese privacy-regels (AVG)
Als je data verwerkt van Europese klanten (namen, e-mails, financiële gegevens, medische informatie), valt dat onder de AVG. Bolt, v0, Replit, Retool en Rocket.new zijn Amerikaans. Data op Amerikaanse servers mag onder AVG alleen met duidelijke afspraken — en de meeste platforms maken dat niet transparant genoeg voor zakelijke toepassingen.
Lovable is Zweeds (EU-bedrijf), wat helpt, maar de onderliggende diensten zoals Supabase kunnen alsnog in de VS draaien. Voor normale projecten zelden een probleem; voor B2B-software, zorg, overheid, financieel of HR is het een serieus aandachtspunt.
Meer over AVG en software: AVG/GDPR voor webapplicaties.
3. Hosting en beschikbaarheid
Je hosting zit vast aan het platform. Geen keuze over waar je data staat, welke back-ups er worden gemaakt, of wat er gebeurt als het platform zelf storing heeft. Als Lovable of Bolt uitvalt, ben jij ook offline — en je kunt niks doen behalve wachten. Geen failover, geen eigen monitoring, geen eigen serverinfra om op terug te vallen.
4. Beveiliging
AI-gegenereerde code heeft statistisch gezien vaker beveiligingslekken dan handgeschreven code. Denk aan: mensen die ongewenst bij data van andere gebruikers kunnen, wachtwoorden die niet goed zijn opgeslagen, of inloggegevens die per ongeluk in openbare code terechtkomen. De AI weet niet wat jouw risico-situatie is — dat moet een mens beoordelen.
Wat Coding Agency al heeft opgepakt rond vibe-coding
De afgelopen maanden hebben we meerdere projecten begeleid waar vibe-coding een rol speelde. Onze aanpak is altijd hetzelfde: het platform is het middel, het doel is een werkend product dat past bij wat de klant nodig heeft. Een paar voorbeelden van hoe dat eruit kan zien:
Voorbeeld 1 — Solo-oprichter met Lovable-SaaS
Een oprichter had in Lovable een SaaS-tool gebouwd voor een specifieke niche, met betalende klanten vanaf dag één. Na een half jaar liep hij tegen grenzen: complexere gebruikersrollen, koppelingen met externe systemen, en zorgen over of zijn klanten (allemaal in de EU) juridisch veilig waren. Wij hebben zijn project als blauwdruk genomen en een Laravel-versie gebouwd op eigen EU-hosting. Hij kon door blijven itereren in Lovable terwijl wij bouwden, en de laatste features hebben we samen overgezet. Looptijd: 5 weken. De oprichter houdt nu volledige controle en zijn AVG-compliance is keurig.
Voorbeeld 2 — Medewerker met een Bolt-prototype
Een medewerker van een middelgrote MKB-klant had in Bolt.new een interne tool gebouwd die het werk van zijn team aanzienlijk versimpelde. Het management was enthousiast over het idee, maar zag niet direct dat Bolt geen productie-omgeving was. Wij hebben eerst een Technical Assessment gedaan om de situatie helder te maken (inclusief eerlijke inschatting wat het zou kosten als het platform zou uitvallen). Op basis daarvan kreeg de medewerker groen licht voor een professionele herbouw. De originele Bolt-app fungeerde als scope-definitie — alles wat de MVP deed, zat in de maatwerk-versie, plus goede gebruikersrollen, audit trails en koppeling met hun bestaande systemen.
Voorbeeld 3 — Zorg-startup met v0 + Supabase
Een startup in de zorg had hun patiëntenportaal gebouwd met v0 voor de vormgeving en Supabase voor de data. Toen ze klaar waren voor hun eerste klant (een zorginstelling) bleek dat de AVG-compliance niet op orde was. Wij hebben een Technical Assessment gedaan, dataflow in kaart gebracht en een migratieplan opgesteld. Ze hebben eerst de meest urgente zaken laten oplossen en komen binnenkort terug voor de volledige migratie. Het rapport heeft ze helpen binnenhalen van hun eerste klant, omdat ze nu concreet konden laten zien welke stappen gepland waren.
Wanneer blijf je beter bij vibe-coding?
Niet elk vibe-coding project hoort gemigreerd te worden. Blijf lekker in Lovable, Bolt of v0 als:
- Je MVP nog niet is gevalideerd — eerst betalende klanten, dan praten over maatwerk
- Het gaat om een marketing-site of landingspagina zonder gebruikersaccounts
- Het een tijdelijk experiment is dat je binnen enkele maanden kunt loslaten
- Er geen gevoelige data wordt verwerkt en geen omzet van afhangt
Wanneer is het tijd om over te stappen?
Je ziet vrijwel altijd dezelfde signalen:
- Je hebt betalende klanten en je platform-kosten beginnen op te lopen
- Je wil koppelingen met boekhoudsoftware, CRM of specifieke API's die jouw platform niet biedt
- Gebruikersrollen worden ingewikkeld — verschillende rechten voor verschillende gebruikers
- Je data is gevoelig (AVG, medische data, financieel) en compliance wordt belangrijk
- Downtime is een probleem — je klanten verwachten dat de app het doet
- Je wil sneller ontwikkelen dan het platform toestaat
Herken je drie of meer van deze punten? Dan is het tijd om minstens een Technical Assessment te overwegen — daarmee krijg je een eerlijk beeld zonder dat je direct vast zit aan een migratietraject.
Onze positie samengevat
Wij zien vibe-coding als een waardevolle tool in het ontwikkel-landschap. Voor de vroege fase van een idee, voor interne experimenten, voor mensen die snel willen valideren — uitstekend. Voor alles wat daarna komt, voor het moment dat je een écht bedrijf bouwt op je idee, heb je een fundament nodig dat mee kan groeien.
Zie je vibe-coding project als je MVP. Wij nemen het daarna over — met jouw werkende app als blauwdruk, en een nette maatwerk-versie als eindresultaat.
