Wat er gebeurt na het vibe-coden: van prototype naar onderhoudbaar product

Vibe-coden heeft een nieuwe groep builders gecreeerd. Met AI-tools als Cursor, Copilot of Lovable bouw je in een weekend een werkend prototype. De drempel is laag, de snelheid hoog, en het resultaat voelt verrassend solide. Tot het dat niet meer is.

Zes maanden later zit je met een codebase die niemand snapt, tests die ontbreken, en een feature-request die twee weken kost terwijl hij in de eerste sprint een dag had gekost. Bij Livewall zien we dit patroon regelmatig. Niet omdat vibe-coden slecht is, maar omdat de stap van prototype naar product structuur vraagt die je in de sprint-modus bewust hebt overgeslagen.

Waarom prototypes zo snel rotten

Een prototype is gebouwd om een idee te bewijzen. Elke beslissing in die fase is gericht op snelheid: geen abstractielagen, geen foutafhandeling, geen nagedachte over wat er gebeurt als twee gebruikers tegelijk iets doen. Dat is prima. Dat is precies hoe het hoort.

Het probleem ontstaat wanneer je die prototype-mindset meeneemt de productfase in. Elke nieuwe feature wordt erbovenenop gestapeld. De codebase groeit, maar de structuur niet. Op een gegeven moment kost een kleine aanpassing een uur debuggen omdat niemand meer begrijpt hoe de onderdelen aan elkaar hangen.

Dit is geen falen van de technologie. Het is een overgangsmoment dat om een ander soort werk vraagt: scale-up development. Niet opnieuw beginnen, maar bewust opbouwen vanuit wat al werkt.

De drie signalen dat je klaar bent voor de overstap

Niet elk prototype heeft een scale-up nodig. Sommige ideen sterven na de eerste gebruikerstest, en dat is de goedkoopste uitkomst die er is. Maar als je het volgende herkent, is het tijd:

Echte gebruikers hangen eraan. Niet een handvol testpersonen, maar mensen die de app dagelijks gebruiken en er echt op rekenen. Op dat moment mag een bug geen dagenlange uitval veroorzaken.

Het team groeit. De eerste developer wist alles uit zijn hoofd. De tweede moet het uitgelegd krijgen. Als je kennis alleen in hoofden zit, is dat een risico.

Features worden trager, niet sneller. In de eerste weken was alles snel. Nu kost een nieuwe integratie drie keer zoveel tijd als verwacht. Dat is geen toeval, dat is technische schuld die rente vraagt.

Bij producten als Dumpert en Sportvisunie zagen we dit moment komen. De initieel gebouwde versie werkte. De vraag werd: hoe laat je hem groeien zonder dat de bodem eruit valt?

Wat scale-up development concreet inhoudt

De term klinkt abstract, maar het werk is specifiek. Dit zijn de stappen die wij zetten als we een prototype overnemen of een bestaand product professionaliseren:

Codebase-audit. Niet om te oordelen over wat er staat, maar om te begrijpen wat er is. Welke onderdelen zijn fragiel? Waar zijn de afhankelijkheden onduidelijk? Wat werkt beter dan verwacht en hoeft niet aangeraakt te worden?

Testdekking opbouwen. Vibe-code heeft zelden geautomatiseerde tests. Dat is de eerste prioriteit: kritische paden vastleggen zodat je niet elke release handmatig hoeft te controleren. Dit lijkt traag, maar maakt elke volgende stap sneller.

Infrastructuur herbeoordelen. Het serverloze hostingplan dat voor een prototype prima was, is misschien niet wat je nodig hebt voor duizend gebruikers. Webapplicatie-ontwikkeling op schaal begint met de juiste basis.

Documentatie schrijven. Niet een 40-pagina document, maar de essentials: hoe start je de lokale omgeving, wat doet welke service, waar zitten de koppelvlakken. Genoeg zodat een nieuwe developer in een dag productief kan zijn.

Refactoren met aandacht. Niet alles herschrijven. Selectief verbeteren op de plekken waar de technische schuld de meeste wrijving veroorzaakt. De rest laten staan.

De rol van AI in het scale-up proces

Hier wordt het interessant. Dezelfde AI-tools die het vibe-coden mogelijk maakten, kunnen ook helpen bij de professionaliseringsslag. Maar de manier waarop verschilt.

Bij het prototypen gebruik je AI om snel te genereren. Bij scale-up gebruik je AI om te begrijpen en te verbeteren. Denk aan: geautomatiseerde testgeneratie op basis van bestaande code, documentatie die AI opstelt op basis van de codestructuur, refactoringsuggesties die consistent zijn met de patronen die al in de codebase zitten.

Bij Livewall werken we nauw samen met Mach8, onze zusterorganisatie voor AI-automatisering, als het gaat om AI-gedreven tooling in productworkflows. De combinatie van snelle bouw en slimme automatisering is de kern van hoe we custom tooling voor klanten aanpakken.

Maar: AI vervangt het architectuuroordeel niet. De beslissing of je een monoliet of microservices gebruikt, of je een externe API direct aanroept of een abstractielaag bouwt, dat zijn keuzes die context vragen die een taalmodel niet heeft.

Hoe je de overdracht aan andere developers voorbereidt

Een prototype is vaak gebouwd door een of twee mensen die alles in hun hoofd hebben. De overgang naar een bredere ontwikkelaarsbasis is een van de kwetsbaarste momenten in de productlevenscyclus.

Expliciete beslissingslog. Waarom is gekozen voor framework X in plaats van Y? Als die redenering nergens staat, wordt elke nieuwe developer gedwongen om de keuze opnieuw te maken of het verkeerd te begrijpen.

Gestandaardiseerde omgeving. Eén commando om de lokale omgeving op te starten. Geen handmatige stappen, geen "vraag maar aan de founder". Dit klinkt triviaal, maar het is een van de meest effectieve manieren om onboardingtijd te verkorten.

Kleine, gerichte pull requests. De cultuur van grote batches die de prototype-fase kenmerkt, werkt niet meer als je met meerdere mensen aan dezelfde codebase werkt. Kleine PRs zijn makkelijker te reviewen en makkelijker terug te draaien.

Dit is precies de werkwijze die we hanteren bij interne systemen en platformen die door interne teams beheerd moeten worden. Denk aan wat we bouwden voor Zorg van de Zaak: een B2B-platform dat door een niet-technisch beheersteam onderhouden moet kunnen worden.

Begin klein, maar bouw met het einde in gedachten

Bij Livewall is ons uitgangspunt niet: bouw zo solide mogelijk vanaf dag een. Dat vertraagt je en je lost problemen op die je misschien nooit krijgt. Ons uitgangspunt is: begin klein, maar maak bewuste keuzes die de scale-up later niet blokkeren.

Dat betekent: kies frameworks met een actieve community. Schrijf ook in de prototype-fase minstens tests voor de allerkritiekste paden. Houd je data-laag gescheiden van je presentatielaag. Gebruik versiebeheer consequent, ook als je alleen werkt.

Deze gewoontes kosten weinig tijd in de prototype-fase, maar ze maken het verschil als je zes maanden later terug moet in de code. De producten die wij het langst succesvol zien functioneren, zoals Lefboom en InShared, zijn niet de producten die het perfect begonnen. Het zijn de producten waarbij elk nieuw hoofdstuk bewust begon.

De overgang van vibe-code naar product is geen one-time event. Het is een manier van werken. En die overgang goed maken is precies wat scale-up development bij Livewall inhoudt.