Een MVP in 14 dagen bouwen met AI-versnelde softwareontwikkeling

Vroeger kocht je met twee weken budget een functioneel ontwerp. In 2026 koop je er een werkend product mee, met echte gebruikers, echte betalingen en een AI-functie die echt iets doet. Het addertje: snelheid is goedkoop geworden. Wat een product overeind houdt – beveiliging, een goed datamodel, meetbare AI-kwaliteit en kostenbeheersing – is dat niet.

Deze gids laat zien hoe een MVP van 14 dagen werkt als hij ontwikkeld wordt in plaats van alleen gegenereerd: wat er in die periode past, een plan per dag, wat het op de huidige markt kost, hoe een eerlijke offerte met vaste prijs eruitziet en welke fouten van een snelle lancering een dure herbouw maken.

Waarom 14 dagen realistisch is geworden

De tools zijn sneller veranderd dan de meeste budgetten. Lovable passeerde in februari 2026 een jaarlijkse terugkerende omzet (ARR) van $ 400 miljoen, met slechts 146 medewerkers en zo’n 8 miljoen gebruikers die samen meer dan 200.000 projecten per dag starten (TechCrunch). Prototypes, landingspagina’s en eenvoudige interne apps bouwen oprichters nu in een weekend zelf.

Ook bij echte producten is het effect zichtbaar. Volgens Bitsens neemt een AI-builder nu zo’n 70% over van werk dat vroeger 200–300 ontwikkeluren kostte; voor een developer blijven 60–120 uur over. Studio’s met een vaste prijs, zoals HouseofMVPs, leveren MVP’s in pakketten van één tot vier weken.

Toch maakt AI niet elk team sneller. In een gecontroleerd onderzoek van METR waren ervaren opensource-ontwikkelaars met AI-tools 19% trager, terwijl ze dachten dat ze 20% sneller waren geweest. In de Stack Overflow Developer Survey 2025 noemde 66% van de ontwikkelaars AI-oplossingen die “bijna goed” zijn hun grootste ergernis, en 46% vertrouwt de nauwkeurigheid van AI-output niet.

De les: AI versnelt het typen, niet het oordeel. Een MVP van 14 dagen werkt als senior ontwikkelaars AI inzetten voor het volume – boilerplate, schermen, tests, migraties – en architectuur, datamodel, security-review en acceptatie stevig in menselijke handen houden.

Wat er in 14 dagen past, en wat niet

De belangrijkste beslissing valt voordat er één regel code is geschreven. Doe de één-zin-test: “Een [specifieke gebruiker] kan [één ding doen] en krijgt [één meetbaar resultaat].” Heb je twee zinnen nodig, dan is de scope nog niet klaar voor een sprint van 14 dagen.

Een goed team gaat in het eerste gesprek al in discussie over de scope. Dat is geen gebrek aan ambitie: het is precies het mechanisme dat een vaste deadline mogelijk maakt.

Het 14-dagenplan, dag voor dag

Dag 1–2: scope vastleggen en ontwerpen

De sprint begint met een werksessie, niet met code. De uitkomst is een kort document dat beide partijen ondertekenen:

• De gebruiker en de taak: wie gebruikt het product en wat wil die persoon voor elkaar krijgen?
• De succesmaatstaf: bijvoorbeeld “een recruiter selecteert 20 cv’s in minder dan 10 minuten” of “een klant krijgt een offerte zonder te bellen”.
• Acceptatiecriteria: concrete, toetsbare uitspraken waaraan het eindproduct wordt getoetst.
• De “niet nu”-lijst: alles wat besproken is en bewust naar versie twee is verschoven.

Ondertussen maken AI-tools binnen enkele uren klikbare wireframes, zodat de opdrachtgever reageert op schermen in plaats van op abstracties. Het datamodel ontwerpt een mens: entiteiten, eigenaarschap en wie wat mag lezen of wijzigen. Hier gaan de meeste vibe-coded apps de mist in, en juist dit is later het duurst om te repareren.

De AI-functie krijgt een eigen “contract”: invoer, verwacht uitvoerformaat, wat er gebeurt als het model twijfelt, en de maximale kosten per aanroep.

Dag 3–5: van skelet naar staging

• De repository wordt aangemaakt in de GitHub-organisatie van de klant, niet bij het bureau.
• Continuous integration draait vanaf de eerste commit: linting, tests, secret scanning en controle van afhankelijkheden.
• Authenticatie, de database met toegangsregels per rij en de deployment-pipeline worden ingericht.
• Uiterlijk op dag 5 staat er een staging-URL online. Dat is de standaard van de betere studio’s met vaste prijs (HouseofMVPs), en vanaf dat moment heeft de opdrachtgever elke dag iets echts om te proberen.

Dag 6–10: de kernflow en de AI-functie

Eerst wordt de hoofdroute van begin tot eind gebouwd, daarna de uitzonderingen: lege schermen, fouten, herhaalpogingen, rechten. Hier levert AI-ondersteund programmeren de meeste winst op.

De AI-functie wordt gebouwd als software, niet als een prompt in een tekstvak:

• Gestructureerde output met validatie, zodat de rest van de app nooit verrast wordt door vrije tekst.
• Een evalset met echte voorbeelden – meestal enkele tientallen tot honderd – met per voorbeeld het verwachte resultaat. Elke wijziging in prompt of model draait opnieuw tegen die set.
• Modelroutering: een goedkoop, snel model voor classificatie en extractie, een sterker model alleen waar redeneren nodig is.
• Kostenlogging per verzoek, zodat je weet wat een gebruikersactie kost voordat je duizenden gebruikers hebt.

Elke dag eindigt met een korte demo op staging. Feedback komt dezelfde middag binnen, niet aan het eind van de sprint.

Dag 11–12: betalingen, hardening en security-review

• Betalingen, transactionele e-mails, foutmonitoring en productanalytics worden aangesloten. Goed georganiseerde studio’s gebruiken bijvoorbeeld Langfuse of Helicone voor modelobservability, plus Sentry en PostHog (HouseofMVPs).
• Een aparte security-review controleert de code voor authenticatie en autorisatie, elk API-endpoint, de databaseregels, secrets en afhankelijkheden. Dat laatste is belangrijker dan het klinkt: volgens de Cloud Security Alliance bestaat 19,7% van de pakketten die AI-modellen voorstellen niet – een uitnodiging aan aanvallers om juist die namen te registreren.
• De evalset draait nog een keer tegen de bijna definitieve versie.

Dag 13–14: acceptatie en overdracht

Het product wordt getest tegen de ondertekende acceptatiecriteria en in productie gezet. Dan volgt het overdrachtspakket, en dat maakt het verschil tussen een MVP en een demo:

• architectuuroverzicht en een runbook voor veelvoorkomende handelingen;
• alle omgevingsvariabelen, sleutels en accounts op naam van de klant;
• het evalrapport en het beveiligingsrapport;
• een kostendashboard met modeluitgaven per dag en per functie;
• een geprioriteerde backlog voor versie twee.

Wat een MVP van 14 dagen kost in 2026

De prijzen lopen sterk uiteen, omdat “MVP” heel verschillende dingen kan betekenen. De tabel vat gepubliceerde marktcijfers samen.

Bronnen: Bitsens, HouseofMVPs, Groovy Web. Veel cijfers komen uit publicaties van de aanbieders zelf; zie ze als marktindicatie, niet als onafhankelijke statistiek.

Twee kostenposten worden vaak vergeten:

1. AI-functies maken een MVP 15–30% duurder dan een vergelijkbaar product zonder AI (Bitsens). Dat geld gaat naar evals, vangrails en kostenbeheersing – en is daar goed besteed.
2. Het gebruik van model-API’s wordt meestal apart afgerekend, rechtstreeks door de klant aan de aanbieder (HouseofMVPs). Voor een MVP is dat vaak een paar tientjes per maand; op schaal verbruikt een gemiddelde agent $ 50–500 per maand aan modelkosten (Lets-Viz).

Zo ziet een eerlijke offerte met vaste prijs eruit

De markt is uitgekomen bij voorwaarden die beide partijen beschermen. Gebruik ze als checklist bij het vergelijken van offertes:

• Scope ondertekend vóór betaling, met acceptatiecriteria en een “niet nu”-lijst.
• Prijs vast bij ondertekening, meestal 50/50 betaald; meerwerk binnen de afgesproken scope komt voor rekening van de studio.
• Staging-URL op dag 5, dagelijkse of bijna dagelijkse demo’s.
• Code en IE-rechten vanaf dag één van jou: jouw repository, jouw cloud, jouw modelaccounts.
• Eval-harness en kostenmonitoring inbegrepen, niet als meerprijs.
• Een garantieperiode van 30–60 dagen voor fouten na de lancering.
• Een schriftelijk beveiligingsrapport bij oplevering.

Deze voorwaarden komen overeen met de pakketten die HouseofMVPs beschrijft. De bredere markt beweegt dezelfde kant op: Tenex factureert per opgeleverd story point in plaats van per uur, en Distyl koppelt een deel van zijn honorarium aan de resultaten van de klant (Built In, Channel Dive). Krijg je een offerte puur op uurbasis zonder vaste scope, dan ligt al het risico bij jou.

Maak de AI-functie meetbaar

De meeste MVP’s “met AI” kunnen een simpele vraag niet beantwoorden: hoe vaak is de AI-output goed genoeg? Beantwoord die vraag vóór de lancering.

• Kies één kwaliteitsmaatstaf per AI-functie: nauwkeurigheid van extractie, aandeel concepten dat zonder aanpassing wordt overgenomen, aandeel antwoorden met bronvermelding.
• Bouw de evalset met echte data, inclusief de lastige gevallen: gescande pdf’s, gemengde talen, onvolledige invoer.
• Ontwerp het faalpad. Bij lage zekerheid vraagt het product om bevestiging of geeft het over aan een mens, in plaats van te gokken.
• Begrens de uitgaven per gebruiker en per maand, met een alarm bij afwijkingen.
• Maak AI kenbaar waar dat moet. Volgens artikel 50 van de Europese AI Act moeten chatbots sinds 2 augustus 2026 vermelden dat gebruikers met AI praten (Cooley).

Deze praktijken werken we verder uit in onze gidsen over AI-kwaliteit meten met evals en LLM-gateways en kostenbeheersing.

Veelgemaakte fouten die van 14 dagen 4 maanden maken

1. Scope creep vermomd als “kleine toevoeging”. Elke toevoeging klinkt onschuldig, samen blazen ze de deadline op. Alles wat nieuw is, gaat tot de lancering op de “niet nu”-lijst.
2. De gegenereerde demo opleveren als product. Een onafhankelijke scan van 5.600 openbare vibe-coded apps vond meer dan 2.000 ernstige kwetsbaarheden, 400 blootgestelde secrets en 175 gevallen van gelekte persoonsgegevens (SoftwareSeni). Heb je al zo’n app, begin dan met onze checklist voor de beveiligingsaudit van vibe-coded apps.
3. Geen nulmeting. Volgens het MIT NANDA-rapport heeft zo’n 95% van de generatieve-AI-pilots geen meetbaar effect op de winst-en-verliesrekening (Fortune). Op de methode is kritiek (Marketing AI Institute), maar het patroon klopt: zonder “voor” kun je geen “na” bewijzen.
4. Platform-lock-in zonder exitplan. Alles bouwen binnen één builder met de bijbehorende gehoste database gaat snel, tot je moet verhuizen. Spreek op dag één af hoe je exporteert; zie ook eigenaar blijven van code, prompts en data.
5. Onbeperkte modelkosten. Eén lusfout of één kwaadwillende gebruiker kan in één nacht een maandbudget opmaken. Budgetlimieten horen in de eerste release.
6. Een exotische techstack. Veertien dagen is niet het moment om een nieuw framework uit te proberen. Saaie, goed gedocumenteerde techniek is een feature.
7. Geen analytics. Een MVP bestaat om te leren. Zie je niet waar gebruikers afhaken, dan heb je een gok opgeleverd.

Na dag 14

De lancering is het begin van de leercyclus, niet het einde van het project. Een verstandig plan voor de weken erna:

• Garantieperiode (30–60 dagen): fouten uit echt gebruik worden zonder meerkosten opgelost.
• Wekelijkse blik op gebruik en AI-kwaliteit: de evalset groeit mee met echte gevallen die misgingen.
• Versie twee op basis van data, niet van wensen: de “niet nu”-lijst wordt opnieuw geprioriteerd op basis van wat gebruikers echt doen.
• Een beheercontract als je geen eigen ontwikkelaars hebt: monitoring, modelupdates, maandelijkse evals en een kostenrapport.

Voor het mkb is dat laatste punt cruciaal. Volgens Eurostat gebruikte in 2025 slechts 17% van de kleine Europese bedrijven AI, tegen 55% van de grote. Het verschil zit zelden in ideeën en vaak in de vraag wie het systeem na de lancering draaiende houdt. Bouw je technisch vernieuwende software, laat dan ook nagaan of de WBSO-regeling van RVO voor jouw project van toepassing is.

Conclusie

Een MVP in 14 dagen is geen marketingslogan meer. AI-tools nemen het meeste volumewerk over, en een sprint met vaste prijs en vaste scope levert in twee weken een echt product op, met gebruikers en betalingen. Wat niet is veranderd, is waar producten op stuklopen: een onduidelijke scope, een zwak datamodel, een ontbrekende security-review, ongemeten AI-kwaliteit en onbegrensde kosten. Behandel die vijf punten als niet onderhandelbaar en de snelheid is puur voordeel.

Heb je een idee en wil je weten of het in een sprint van twee weken past? Ons Build-team geeft je snel een eerlijk antwoord. Plan een gratis audit van 15 minuten – je hoort wat past, wat niet en wat ervoor nodig is.