Lovable- of Bolt-app laten afmaken

Waarom loopt een vibe-coded app vast?

Vibe coding is bouwen door in gewone taal te beschrijven wat je wilt, terwijl AI de code schrijft. Andrej Karpathy gaf het in februari 2025 die naam. Tools als Lovable, Bolt.new en Replit maken het mogelijk om in een paar dagen iets te hebben wat eruitziet als een complete app, met schermen, een database en een inlogscherm.

Dat is een echte stap vooruit. Je kunt een idee laten zien, testen met de eerste gebruikers en ontdekken wat werkt. Het probleem begint meestal later, op een van deze momenten:

• Elke nieuwe prompt breekt iets anders. De AI past een scherm aan en een functie elders werkt niet meer. Hoe groter de app, hoe vaker dit gebeurt.
• De credits of tokens raken snel op. Je betaalt steeds opnieuw voor pogingen om dezelfde fout op te lossen.
• Echte gebruikers en echte gegevens. Zodra klanten inloggen, betalen of persoonsgegevens achterlaten, moet de app veilig zijn. Dat zie je niet aan de buitenkant.
• Iets wat de bouwer niet goed kan. Een koppeling met een ander systeem, ingewikkelde rekenregels, rollen en rechten of een app in de appwinkels.
• Iemand anders moet verder. Een ontwikkelaar, investeerder of klant wil weten wat er onder de motorkap zit.

Op dat punt heb je geen nieuwe prompt nodig, maar iemand die de code leest en begrijpt.

Wat AI-bouwers wel en niet voor je regelen

De tools verschillen, maar het patroon is vergelijkbaar. Ze zijn sterk in de zichtbare kant van een app en zwakker in alles wat eronder moet kloppen.

Volgens Rapidevelopers brengt Lovable een project typisch 60 tot 80% richting productie. Het resterende deel bestaat uit randgevallen, complexe bedrijfslogica en prestaties, en dat vraagt meestal handwerk van een ontwikkelaar. Zapier komt met ongeveer 70% op hetzelfde beeld uit.

Beveiliging is het belangrijkste werk

Een taalmodel doet wat je vraagt. Vraag je niet expliciet om beveiliging, dan krijg je die vaak ook niet. Zapier verwijst naar een studie van Carnegie Mellon University waarin een groot deel van de door AI geschreven code functioneel wel werkte, maar maar 10,5% de beveiligingstests doorstond.

Bij apps uit Lovable en Bolt kijk ik daarom altijd naar deze punten:

• Rechten op de database. Bij Supabase bepalen zogenoemde row level security-regels wie welke rijen mag lezen en wijzigen. Ontbreken die of staan ze te ruim, dan kan een ingelogde gebruiker soms gegevens van anderen opvragen.
• Geheime sleutels. API-sleutels voor betalingen, e-mail of AI-diensten horen niet in de code die in de browser draait.
• Controle van invoer. Alles wat een gebruiker invult, moet aan de serverkant worden gecontroleerd, niet alleen in het formulier.
• Rollen. Een beheerder, een medewerker en een klant zien niet hetzelfde. Dat moet in de logica en in de database geregeld zijn, niet alleen door een knop te verbergen.
• Persoonsgegevens. Welke gegevens bewaar je, waar staan ze, wie kan erbij en hoe verwijder je ze weer? Dat zijn vragen die de AVG aan je stelt.
• Betalingen. Een betaling is pas rond als de betaaldienst dat aan je server bevestigt, niet als de gebruiker op een bedankpagina landt.

Een beveiligingsscan in de tool zelf is een goed begin, maar vervangt geen controle van de logica. Een scan ziet of een regel bestaat, niet of die regel klopt voor jouw situatie.

Afmaken, deels herbouwen of opnieuw beginnen?

Dit is de vraag die het meest bepaalt wat het traject kost. Het eerlijke antwoord komt pas na een controle van de code, maar de afweging ziet er meestal zo uit.

Opnieuw beginnen klinkt als verspilling, maar dat is het zelden. De vibe-coded versie heeft dan haar werk gedaan: je weet welke schermen nodig zijn, welke volgorde gebruikers volgen en welke functies er echt toe doen. Dat is precies wat een eerste versie hoort op te leveren. Een nieuwe opbouw gaat met die kennis veel sneller dan een project dat vanaf een leeg vel begint.

Afmaken heeft de voorkeur als het kan. Lovable levert standaard React-code met Supabase, en die is voor een ontwikkelaar goed leesbaar. Techsy, een bureau dat regelmatig vibe-coded apps overneemt, schat het verhuizen van zo'n Supabase-app naar een eigen omgeving op 40 tot 80 ontwikkeluren en adviseert eerst een audit van de codebase.

Stappenplan: van prototype naar app voor echte gebruikers

Deze stappen vormen de kern van het afmaken. De volgorde is belangrijk: eerst begrijpen, dan repareren, dan uitbreiden.

1. Code uit de bouwer halen. Zet het project in een eigen GitHub-repository. Dan heb je versiebeheer, kun je terug naar een vorige versie en ben je niet afhankelijk van één tool.
2. Controle van de codebase. Hoe is de app opgebouwd, welke onderdelen worden gebruikt, waar zitten dubbele of dode stukken code, hoe ziet de database eruit?
3. Beveiliging en rechten. Rechten op de database, geheime sleutels, rollen, controle van invoer en de afhandeling van betalingen.
4. Belangrijkste routes vastleggen. Welke taken moeten altijd werken? Bijvoorbeeld registreren, inloggen, een aanvraag doen, betalen. Daarvoor komen automatische tests.
5. Foutafhandeling. Wat ziet een gebruiker als iets misgaat, en krijg jij daar een melding van?
6. Testomgeving en productieomgeving. Wijzigingen eerst testen op een kopie, daarna pas live zetten.
7. Hosting, back-ups en monitoring. Waar draait de app, hoe vaak wordt de database veiliggesteld en hoe merk je dat de app traag of onbereikbaar is?
8. Privacy en voorwaarden. Een privacyverklaring die klopt met wat de app echt doet, en waar nodig een verwerkersovereenkomst met de diensten die je gebruikt.
9. Daarna pas uitbreiden. Nieuwe functies bouw je op een fundament dat je begrijpt.

Je kunt na het afmaken vaak gewoon verder met AI-tools. Het verschil is dat er dan een structuur, tests en versiebeheer zijn, zodat een fout van een prompt niet ongemerkt live gaat.

Een webapp of een app in de appwinkels?

Lovable bouwt alleen webapps. Dat zijn apps die in de browser draaien, ook op een telefoon. Voor veel zakelijke toepassingen is dat genoeg en zelfs handiger: één versie, geen goedkeuring van Apple of Google, direct bij te werken.

Wil je toch in de App Store of Google Play, dan zijn er twee routes. Je kunt de webapp verpakken in een schil, met diensten als Median. Dat is snel, maar appwinkels wijzen apps met weinig eigen functionaliteit soms af. Of je laat een echte mobiele app bouwen, bijvoorbeeld met React Native. Bolt ondersteunt zulke projecten via Expo, Lovable niet. Reken daarnaast op een Apple Developer-account van $99 per jaar en een eenmalige registratie bij Google Play van $25.

Op de pagina over een webapplicatie laten maken lees je meer over de afweging tussen web en native.

Hoe ik een vibe-coded app overneem

Ik begin met een procesgesprek van ongeveer twintig minuten. Daarin wil ik weten voor wie de app is, welke taak een gebruiker als eerste moet kunnen afronden en waar het nu vastloopt. Ook vraag ik naar de plannen: een interne tool voor tien medewerkers vraagt iets anders dan een product dat je aan honderden klanten wilt verkopen.

Daarna volgt de betaalde blauwdruk. Ik lees de code en de database, zet op een rij wat goed is, wat riskant is en wat ontbreekt, en doe een voorstel: afmaken, deels herbouwen of opnieuw opzetten. Je krijgt daarbij een afgebakende eerste versie: welke routes, welke gebruikers en rollen, welke koppelingen. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen, ook als er al een app ligt.

Dan bouw ik die eerste versie en zet ik hem live. Na de lancering kan ik de app beheren en verbeteren, of zo overdragen dat jij of je eigen team ermee verder kan.

Wat heb ik van je nodig?

Hoe completer het beeld aan het begin, hoe sneller de controle gaat. Dit helpt:

• Toegang tot het project. Een uitnodiging voor het project in Lovable of Bolt, of de GitHub-repository als je die al hebt gekoppeld.
• Toegang tot de database. Bij Supabase een uitnodiging voor het project, zodat de tabellen en rechten te bekijken zijn.
• Een overzicht van de diensten. Welke betaaldienst, e-maildienst, AI-dienst of andere koppeling gebruikt de app, en op wiens naam staan die accounts?
• De belangrijkste routes. Wat moet een gebruiker zeker kunnen? Drie of vier zinnen zijn genoeg.
• Wat er nu misgaat. Een lijstje met fouten, schermafbeeldingen of meldingen van gebruikers.
• Je plannen. Wie gaat de app gebruiken en hoeveel gebruikers verwacht je het komende jaar?

Je hoeft niet technisch te zijn om dit aan te leveren. Ontbreekt er iets, dan zoeken we het samen uit tijdens de blauwdruk.

Wanneer is afmaken (nog) niet nodig?

Niet elke vibe-coded app hoeft direct naar een ontwikkelaar. Gebruik je de app alleen zelf, staan er geen gevoelige gegevens in en kun je zonder problemen terug naar een vorige versie, dan kun je prima verder met de bouwer zelf. Hetzelfde geldt voor een demo voor investeerders of een klikbaar prototype om gebruikers te interviewen.

Het moment verschuift zodra er echte gebruikers bijkomen, er betaald wordt of er persoonsgegevens van anderen in de app staan. Dan ben jij verantwoordelijk voor wat er met die gegevens gebeurt, ook als de code door AI is geschreven. Het feit dat een applicatie gebouwd kan worden, maakt de commerciële vraag bovendien nog niet beantwoord. Een controle vooraf is dan goedkoper dan een probleem achteraf.

Uit eigen werk: Mailyooo, gebouwd in Bolt

Mailyooo is mijn eigen e-mailmarketingsoftware, en ik heb die in Bolt gebouwd. Er zitten contacten, campagnes, formulieren, een verzendwachtrij en uitschrijffilters in. Ik ken het werken met zo'n AI-bouwer dus van binnenuit, inclusief het punt waarop je niet meer kunt volstaan met beschrijven wat je wilt.

De les die ik eruit haal: verzenden is een keten met keuzes. Wie krijgt een bericht, wie juist niet, wat gebeurt er als iemand zich uitschrijft terwijl een campagne al in de wachtrij staat? Een AI-bouwer maakt snel een knop die "verstuur" zegt. Welke regels daarachter moeten gelden, moet je zelf bedenken en vastleggen. Dat geldt voor vrijwel elke vibe-coded app.

Wat kost het om een Lovable-app te laten afmaken?

Er is geen vaste prijs, omdat de staat van de code zo sterk verschilt. Een paar marktindicaties geven wel richting:

• Migratie naar een eigen omgeving: Techsy schat 40 tot 80 ontwikkeluren voor het verhuizen van een Lovable-app met Supabase.
• Uurtarieven: Techsy noemt voor West-Europa €40 tot €100 per uur bij freelancers en €50 tot €150 bij bureaus. Voor aanpassingen aan een bestaande webapplicatie noemt Lunidev €75 tot €125 per uur.
• Lopende kosten: hosting, een database bij Supabase of een vergelijkbare dienst, e-maildiensten en eventueel het abonnement op de AI-bouwer zelf, als je daar mee wilt blijven werken.
• Opnieuw opbouwen: dan gelden de bedragen van een nieuwe app. Op de pagina wat kost een app laten maken staan de marktindicaties per type app.

Het geld dat je in de vibe-coded versie hebt gestoken, is meestal niet weg. Ook als we deels opnieuw bouwen, scheelt een werkend ontwerp veel tijd in het uitzoeken van wat de app moet doen.

Veelgemaakte fouten

• Blijven prompten tegen een fout die terugkomt. Na een paar pogingen kost het meer dan het oplevert. Dan is het tijd om de code te laten bekijken.
• Live gaan met echte gegevens zonder controle van de rechten. De app ziet er goed uit, maar je weet niet wie wat kan opvragen.
• Geen versiebeheer. Zonder GitHub of een vergelijkbare plek is er geen weg terug als een wijziging iets kapotmaakt.
• Functies blijven toevoegen. Elke nieuwe functie op een wankele basis maakt het later lastiger. Eerst stabiel, dan uitbreiden.
• De vibe-coded versie als mislukt zien. Ze heeft je geleerd wat de app moet doen. Gebruik dat.

Op de pagina over een MVP laten bouwen lees je hoe je een eerste versie zo afbakent dat je snel van gebruikers leert, en op app laten maken hoe een volledig traject verloopt.

Veelgestelde vragen

Kan een ontwikkelaar verder met een app uit Lovable of Bolt?

Ja. Lovable levert standaard React-code met een Supabase-database, Bolt laat je kiezen uit verschillende frameworks. Een ontwikkelaar kan de code naar een eigen repository halen, controleren en verder uitbouwen, al moet gegenereerde code vaak eerst worden opgeschoond.

Is een vibe-coded app veilig genoeg voor klanten?

Niet zonder controle. AI-bouwers regelen beveiliging alleen als je er expliciet om vraagt, en in een studie van Carnegie Mellon doorstond maar 10,5% van de gegenereerde code de beveiligingstests. Laat vooral rechten op de database, geheime sleutels, rollen en betalingen controleren voordat echte gebruikers inloggen.

Moet ik mijn Lovable-app opnieuw laten bouwen?

Niet altijd. Is de structuur helder en zitten de problemen in losse onderdelen, dan is afmaken de logische keuze. Breekt elke wijziging iets anders of weet niemand meer hoe de app in elkaar zit, dan is opnieuw opbouwen met de huidige app als ontwerp vaak sneller en goedkoper.

Bronnen

• Zapier, Miguel Rebelo, "Lovable vs. Bolt vs. Replit: Which vibe coding tool is best?" (juli 2026): de 70% van de weg en de studie van Carnegie Mellon naar beveiliging.
• Rapidevelopers, "Lovable Review 2026": 60 tot 80% richting productie en de beperking tot webapps.
• Techsy, "Lovable vs Bolt vs v0 vergelijking": React en Supabase als output, 40 tot 80 uur migratie en het advies om de code te auditen.
• Lunidev, "Wat kost een custom web applicatie in 2026?": uurtarieven voor aanpassingen aan een bestaande webapplicatie.
• Seahawk Media, "Kan Lovable mobiele apps bouwen?": de route via Median naar de appwinkels.
• Apple Developer Program en Google Play Console: kosten van de ontwikkelaarsaccounts.

Alle bedragen zijn marktindicaties uit deze bronnen en geen prijsopgave.