MVP first: hoe je AI over-engineering voorkomt

Neem het voorbeeld van een startup-oprichter die onlangs zijn eerste productlancering analyseerde. Zijn team had ongeveer vijf maanden en iets meer dan € 80.000 gespendeerd om met behulp van Lovable, Claude code en soortgelijke AI-tools "het platform" te bouwen—compleet met twee dashboards, drie gebruikersrollen, een facturatiemodule en een gelikt notificatiecentrum. Ondanks de zeer professionele oplevering, werd het product gelanceerd met nul betalende klanten. Toen de oprichter achteraf de statistieken bekeek om te zien hoeveel mensen het systeem daadwerkelijk hadden gebruikt, was de realiteit hard: hooguit twee van zijn medeoprichters hadden ooit fatsoenlijk ingelogd.

Dat verhaal is niet langer ongebruikelijk. AI-coderingstools zijn zo goed in het genereren van features dat het natuurlijke budgetsignaal — "we kunnen het ons nog niet veroorloven om dat te bouwen" — stilletjes is verdwenen. En als de frictie verdwijnt, verdwijnt ook de discipline.

Waarom dit steeds weer gebeurt

Vóór AI was de scope zelflimiterend. Een instellingenscherm was een volle week werk, dus je vroeg je af of je het wel nodig had. Nu is het een goede prompt en een kop koffie, dus je vraagt het niet. Het punt is dat elk scherm dat je toevoegt nog steeds een beslissing is die de gebruiker moet maken, en die beslissingen stapelen zich op tot een product dat voor iedereen opgeblazen aanvoelt, behalve voor het team dat het heeft gebouwd.

Het andere wat ons opvalt — en ik heb mezelf er ook op betrapt — is dat het polijsten van een demo productief aanvoelt op een manier die het tonen aan een vreemde niet doet. Niemand heeft bezwaar tegen een Figma. Een klant zal je absoluut vertellen dat je onboarding verwarrend is.

Wat we daadwerkelijk doen bij nieuwe projecten

We zijn geen evangelisten van een specifieke methodologie. Maar we hebben een ritme gevonden dat werkt voor producten in een vroeg stadium:

De eerste twee weken zijn voor discovery, en eerlijk gezegd besteden we de meeste tijd aan het schrappen van dingen. We schrijven de kleinste workflow op die plausibel nuttig zou kunnen zijn voor één specifieke persoon, en we verwijderen al het andere uit het scopedocument. Niet "uitstellen" — verwijderen. Je kunt het later altijd weer toevoegen; dat doe je bijna nooit.

Dan bouwen we ongeveer vier tot zes weken. AI-tooling met een senior engineer die de output in de gaten houdt. Eén end-to-end journey. Geen admin panels, geen rolhiërarchieën buiten "de gebruiker" en "wij", niets configureerbaars. Het zal onderontwikkeld aanvoelen. Dat is het punt.

En dan — dit is het deel dat het vaakst wordt overgeslagen — zitten we naast vijf of tien echte gebruikers terwijl ze het proberen. Geen enquête, geen interview. Kijken. Wat ze doen is bijna nooit wat je dacht dat ze zouden doen, en de roadmap die je in het vliegtuig naar huis schrijft, lijkt in niets op degene waarmee je begon.

Een recente case: Orenita

Orenita is een Nederlands platform voor leveranciers van apparatuur die demo-uitleen en verhuur beheren. Historisch gezien leefde die workflow — aanvraag, goedkeuring, contract, levering, retour, conditierapport, facturatie — verspreid over spreadsheets, e-mailthreads en papier. Een zeer oplosbaar probleem, en zeer verleidelijk om te over-engineeren.

We hadden het complete ding op dag één kunnen ontwerpen. Inventaris voor meerdere magazijnen. Verzendintegraties. Een onderdelencatalogus. ERP-synchronisatie. Een klantenportaal. Een installateursapp. De oprichters hadden overal een mening over. In plaats daarvan dekte de eerste release één uitleenflow, voor één type apparatuur, voor één pilotklant. Het werd in ongeveer acht weken gelanceerd.

Kijken hoe die klant het gebruikte, leverde een heel andere roadmap op dan degene die we vooraf zouden hebben geschreven. De foto's van het conditierapport bleken belangrijker te zijn dan de kalenderweergave waar we twee dagen aan hadden besteed. De eigen buitendienstmonteurs van de klant wilden de app liever op hun telefoon dan het salesteam. De ERP-synchronisatie — het ding dat we bijna toch hadden gebouwd — kon nog een kwartaal wachten. Elk van die aanpassingen zou een dure herbouw zijn geweest als we ons er van tevoren aan hadden vastgelegd.

Het huidige product staat op orenita.com. Elke module die nu op de site staat, heeft zijn plek verdiend doordat hij gebruikt werd, niet doordat hij werd bedacht.

Als je op het punt staat iets te beginnen

Een paar dingen om te proberen. Schrijf de enkele journey op die je product moet voltooien, in één zin. Beperk de eerste release tot zes tot acht weken — als een feature niet past, is het een hypothese, geen vereiste. Lanceer het voor een kleine, benoemde pilotgroep, niet voor "de markt". Bouw de tweede golf van features pas nadat een echte gebruiker er twee keer om heeft gevraagd.

AI heeft het bouwen van een MVP goedkoper gemaakt dan ooit. Dat betekent dat de dure fout nu niet is om te weinig te lanceren — het is doen alsof je het product al kent.