Lovable, Bolt, v0: Wanneer Vibe-Coded MVP's een Technische Schuldhypotheek Worden

Vibe-coded applicaties zoals Lovable, Bolt en v0 zijn uitstekend voor prototypes en volstrekt ongeschikt als productie-MVP's. Telkens wanneer zo'n codebase binnenkomt, wordt die opnieuw van de grond af opgebouwd: het opschonen van de structuur, hooks en authenticatie kost meer dan opnieuw beginnen. Dit artikel trekt de grens tussen het prototype dat deze tools aankunnen en de MVP die zij niet aankunnen.

Iedereen is tegenwoordig een programmeur. Een oprichter zonder technische achtergrond kan op zaterdagochtend een SaaS beschrijven in gewone taal en voor de lunch iets op een openbare URL hebben staan. Dat is een echte verschuiving in de manier waarop software tot stand komt, en die is grotendeels positief. Het heeft ook een nieuw faalpatroon gecreëerd dat twee jaar geleden nog niet bestond: productie-applicaties die niemand binnen het bedrijf kan lezen.

Oprichters melden zich wekelijks die een Lovable-build hebben uitgebracht, hun eerste drie klanten hebben getekend, en vervolgens tegen een muur lopen die zij niet kunnen omschrijven. Het platform heeft het werk gedaan. Het platform heeft ook elke architecturale beslissing genomen voordat de oprichter wist welke er toe deden.

Dit artikel bekritiseert Lovable, Bolt of v0 niet. Ze verdienen hun plek in de prototypefase. De grens wordt hier vanuit het perspectief van de afnemer getrokken: wat deze tools opleveren versus wat een MVP nodig heeft om de eerste betalende klant te overleven, inclusief het opschoonpatroon dat terugkeert in elke codebase die ter overname binnenkomt.

• Vibe-coding wint in de prototypefase, waar snelheid structuur verslaat en niets naar klanten wordt uitgebracht.
• MVP's falen anders dan prototypes. Authenticatie, multi-tenancy, een adminscherm en observability zijn niet onderhandelbaar zodra een echte klant inlogt.
• De opschoonkosten zijn de herbouwkosten. Elke overgenomen vibe-coded MVP wordt opnieuw van de grond af opgebouwd. De Lovable-build was verzonken kosten, geen bespaard werk.
• Het patroon is consistent. Slechte structuur, useEffect-misbruik, onnodige re-renders, open backend-routes, slordige authenticatie, in die volgorde.
• Gebruik Lovable voor waar het goed in is. Demo's, interne mockups, ideeverkenning. Huur engineers in voor alles waar een klant voor betaalt.

Iedereen Is Tegenwoordig een Programmeur (en Dat Is Grotendeels Prima)

De drempel voor "ik heb iets gebouwd" is in 2025 ingestort. v0 levert een Next.js-component op basis van een screenshot, Lovable scaffoldt een Supabase-backend op basis van een alinea, Bolt assembleert een gedeployde applicatie in één gesprek, en Replit Agent doorloopt de hele cyclus totdat iets compileert.

Dit is een echte winst voor ideeverkenning. Een niet-ingenieur die vroeger drie weken besteedde aan het zoeken naar een freelancer, kan nu drie uur besteden aan het valideren van het idee in echte pixels. Een ontwerper kan de demo voor zijn pitch bouwen in plaats van die in Figma te mocken. Geen van deze gebruikssituaties vereist productiediscipline.

De problemen beginnen bij de volgende stap, wanneer het prototype wordt omgedoopt tot "MVP", aan een betalende klant wordt getoond en als productiesoftware wordt behandeld. De tooling kondigt niet aan wanneer de grens wordt overschreden. De oprichter weet zelden dat dit is gebeurd.

De Prototypegrens versus de MVP-grens

Een prototype is een vraag. Een MVP is een contract.

Een prototype vraagt: heeft dit idee zin in pixels? Het draait lokaal, faalt luidruchtig en wordt aan niemand uitgebracht. Het faalpatroon is "ik zie dat dit fout is en pas de prompt aan." Het is een leerartefact, en de enige mensen die ermee worden geconfronteerd zijn de oprichter en een bevriende mede-samenzweerder.

Een MVP is de eerste versie die betalende klanten aanraken. Op het moment dat er geld of persoonsgegevens van eigenaar wisselen, verandert ook het impliciete contract. De klant verwacht dat zijn login blijft werken, dat zijn gegevens privé blijven, en dat de applicatie zijn sessie niet verliest omdat een useEffect twee keer is uitgevoerd. Dit zijn geen geavanceerde vereisten, het is het minimum.

De reden dat de meeste vibe-coded applicaties deze grens stilzwijgend overschrijden, is dat de tool bleef beweren "production-ready" te zijn terwijl het een prototype uitbracht. De controle die de overschrijding signaleert is menselijk, niet technisch: een oprichter die weet wat een MVP moet doen voordat het geld kan accepteren.

Wanneer de grens financieel relevant is, is de juiste stap engineers inhuren, niet een snellere prompt. webvise voert MVP-builds uit op een vaste tijdlijn van 3 tot 5 weken, met authenticatie, facturering, een adminscherm en observability die vanaf de kickoff zijn ingebouwd.

Wat Er Werkelijk in Vibe-Coded Codebases Zit

Wanneer een oprichter een Lovable- of Bolt-project aanlevert en om opschoning vraagt, is het patroon zo consistent dat al duidelijk is wat er in zit voordat het repo klaar is met clonen. Vijf problemen, in de volgorde waarin ze schade aanrichten.

Slechte structuur. Bestanden vernoemd naar de prompt die ze heeft gegenereerd, componenten vier niveaus diep genest zonder hergebruiksgrenzen, een "utils"-map met de volledige bedrijfslogica van de applicatie. De codebase is een transcript van hoe de AI dacht, geen beschrijving van wat de applicatie doet. Het toevoegen van een functie betekent de helft van het project doorlezen om te vinden waar de state zich bevindt.

useEffect-misbruik. Elke fetch bevindt zich in een useEffect, elke prop-wijziging triggert een nieuwe fetch, en effects zijn afhankelijk van objecten die bij elke render opnieuw worden aangemaakt. De applicatie bombardeert de backend met dubbele verzoeken bij de eerste weergave en stokt wanneer een van die verzoeken stil faalt. Het patroon verergert zodra er formulieren worden toegevoegd.

Onnodige re-renders. State op het hoogste niveau bevindt zich in een context-provider die de hele applicatie omhult, waardoor elk component opnieuw wordt gerenderd bij elke toetsaanslag. De applicatie voelt traag aan bij 10 items in een lijst en is onbruikbaar bij 100 items. De oplossing vereist echte React-kennis die de prompt nooit heeft gevraagd.

Open backend-routes. Supabase-tabellen waarbij RLS is uitgeschakeld of is ingesteld op "authenticated" zonder rijbegrenzing, serveracties die een door de client verzonden user_id vertrouwen, edge-functies die elke payload accepteren omdat validatie in het formulier zat. Een gebruiker in een incognitovenster kan elke rij in de tabel opvragen.

Slordige authenticatie. Sessiecontroles worden client-side uitgevoerd, rolcontroles worden gedaan met stringvergelijkingen op velden die de AI heeft verzonnen, wachtwoordherstelstromen sturen hetzelfde tokenformaat naar elke gebruiker, JWT-geheimen staan in het .env.example-bestand dat naar de publieke repo is gecommit. Soms is de anonieme sleutel het enige dat staat tussen de applicatie en "ik ben nu admin."

Dit zijn geen randgevallen. Het zijn de mediane uitkomst van "AI heeft dit gebouwd zonder een engineer in de loop", een perspectief dat vanuit technisch oogpunt is uitgewerkt in waarom AI-gegenereerde software nog steeds engineering review nodig heeft.

"Het Werkt" Is het Slechtste Signaal Waarop u Kunt Vertrouwen

Vibe-coded applicaties slagen vaak voor de eerste demo, en precies daar begint het gevaar. De demo draait, de eerste 10 vrienden melden zich aan, de eerste klant betaalt, en de oprichter concludeert dat de build prima was.

De technische schuld stapelt zich stilletjes op totdat iets het naar boven dwingt. De aandrijvende factoren zijn voorspelbaar:

• Eerste echte betalende klant. Zijn gegevens overschrijden uw autorisatiegrens. De grens ontbreekt of is onjuist. U komt dit te weten via een supportticket, niet via een CI-test.
• Eerste functieverzoek na de lancering. Het datamodel van de AI ging uit van één gebruiker per werkruimte. De klant wil er twee. Het toevoegen van de tweede gebruiker raakt 14 bestanden die niemand ooit heeft gelezen.
• Eerste beveiligingsaudit. Een B2B-prospect vraagt om SOC2-documentatie of een pentest. De pentester vindt de open routes in 20 minuten. De deal stagneert of gaat verloren.
• Eerste adminbehoefte. De oprichter moet een klant terugbetalen, een bot blokkeren, of de aanmeldingen van vorige week bekijken. Er is geen adminpagina, en er is geen manier om er een toe te voegen zonder de routing te herzien.
• Eerste schaalevenement. Een blogpost verschijnt, het verkeer piekt, en de applicatie bezwijkt omdat elke render elke rij ophaalt. De oplossing is het re-renderprobleem hierboven.

Elke aandrijvende factor zet onzichtbare schuld om in een storing, een verloren deal of een terugbetaling. De rente op vibe-coded schuld is variabel, en de bank belt op het slechtste moment.

De 100% Herbouwregel

Voor overgenomen vibe-coded MVP's geldt een regel die nog nooit is gebroken: ze worden opnieuw van de grond af opgebouwd.

De redenering is rekenkunde. Om een Lovable-codebase te redden moet elk bestand worden doorgelezen dat de AI heeft geschreven, moet het datamodel worden gedocumenteerd dat de oprichter nooit heeft gezien, de useEffect-keten worden ontward, de routes worden beveiligd, de authenticatie worden hersteld en de structuur worden herstructureerd tot iets dat een mens kan uitbreiden. Dat werk is een volledige herbouw met een extra beperking: breek de klanten niet die al gebruikmaken van de defecte versie.

Een schone herbouw duurt 3 tot 6 weken. Een hersteloperatie duurt 8 tot 12 weken, omdat elke opschoonstap wordt beperkt door het vorige schema en de live data. De "besparingen" van de oorspronkelijke Lovable-build bestaan niet: ze zijn geleend ten laste van de volgende ronde werk.

De eerlijke formulering voor een oprichter: de Lovable-build heeft voor de validatie betaald. Het heeft de eerste klanten binnengehaald, en dat is echte waarde. De code zelf is verzonken kosten. De MVP begint nu.

Hoe een Echte MVP Eruitziet

Ter vergelijking: voor een vastgoeddienst die financieringsverklaringen uitgeeft aan woningkopers is een productie-MVP opgeleverd met een custom workflow in plaats van een vibe-coded scaffold.

De build is een full-stack platform met een financieringsworkflow als kern van de conversie, een admindashboard voor de aanvraagcyclus en geautomatiseerde PDF-certificaatgeneratie binnen het beloofde servicevenster. De stack is Next.js met tRPC voor end-to-end type safety, Drizzle op Neon Postgres en Better Auth voor sessiebeheer. Het contract gebruikte een gescopet leveringsmodel.

Die tijdlijn is geen magie. Ongeveer 85% van elk nieuw project op de stack bestaat uit koppelingen die al bestaan in het vorige project, omdat dezelfde configuratie van Next.js 16, React 19, tRPC v11, Drizzle, Neon, Better Auth, Polar, AI SDK 6 via Vercel AI Gateway en Inngest wordt ingezet bij elke opdracht. De resterende 15% is het werk dat werkelijk uniek is voor deze klant: de domeinlogica, het datamodel, de workflows. AI-tools versnellen die 15% binnen de bestaande structuur, ze vervangen die structuur niet.

Dat is de versie van "AI-native MVP" die de eerste betalende klant overleeft.

Wanneer u Lovable, Bolt of v0 Toch Inzet

Kies het gereedschap op basis van de fase: vibe-coding voor demo's en verkenning, engineers voor betaalde productpaden.

De eerlijke stap voor een oprichter is het prototype op Lovable uitbrengen, valideren, en vervolgens engineers inhuren voordat de eerste betalende klant arriveert. De fout is "het werkt" de build op eigen kracht over de grens laten dragen.

webvise voert MVP-builds uit in 3 tot 5 weken op dezelfde stack die wordt ingezet voor productie-SaaS. Authenticatie, facturering, admin en observability zijn vanaf dag één inbegrepen. Als u een vibe-coded build heeft die vandaag werkt maar u tegenwerkt, vertel wat u ziet en u krijgt een direct antwoord of het een opschoning of een herbouw betreft. Tot nu toe is het antwoord altijd een herbouw geweest.