8 min leestijd

MVP: een test, geen eerste versie

Sébastien Nobour

Oprichter van DEVEDANOS

Praktijken

MVP staat voor minimum viable product: minimaal levensvatbaar product. De term valt zodra het over het lanceren van software gaat, en meestal wordt er een eerste versie mee bedoeld. De applicatie, met minder functionaliteiten.

Allen Holub wijst erop dat er twee definities bestaan. De oudste, die van Frank Robinson, maakt er wel degelijk een product van. Die hebben de meeste mensen in gedachten. De andere komt van Eric Ries, uit The Lean Startup, en Holub vat haar zo samen: “the minimum thing that tests the viability of a product idea”. Het kleinste wat test of een productidee levensvatbaar is.

Het is geen versie 1. Het is helemaal geen product. Het is een test.

Wat is een MVP in softwareontwikkeling?

Een MVP beantwoordt één vraag: is dit product het waard om te ontwikkelen? Slaagt de test, dan is het idee levensvatbaar en wordt bouwen een verstandige stap. Mislukt hij, dan voorkomt u dat er maanden opgaan aan iets waar niemand op zit te wachten.

Het ideale MVP vraagt volgens Holub helemaal geen ontwikkelwerk. Zijn voorbeeld: het MVP van DoorDash was pizza’s bezorgen. Zo werd getest of maaltijdbezorging aan huis levensvatbaar was, zonder één regel code.

Is er toch code nodig, dan blijft het piepklein. Holub heeft het over een MVP dat er “in a day or two, maybe a couple of weeks on the outside” staat. Om daar te komen, neemt hij de methode van Ries over: neem de kleinste set functionaliteiten die u kunt bedenken, halveer die, halveer nog eens, en dan nog een keer. En test maar één ding tegelijk.

In een recenter stuk trekt hij de grens nog krapper. Een software-MVP waarvan het bouwen en live zetten meer dan een paar dagen kost, is volgens hem veel te groot.

Waarom een idee testen voordat het wordt ontwikkeld

Omdat niemand vooraf weet welke ideeën gaan werken. Wanneer Microsoft het effect van zijn ideeën met een gecontroleerd experiment meet, verbetert slechts één op de drie de beoogde indicator. Een derde heeft geen effect, een derde verslechtert hem (Kohavi en Thomke, Harvard Business Review, 2017). Niemand weet van tevoren welke. Dat blijkt pas bij het gebruik.

Zonder test blijkt dat pas als er al gebouwd is.

De maker van een app deed zijn verhaal in een video. Eind 2024 lanceert hij een online softwareproduct, dat hij drie à vier maanden lang in het openbaar bouwt. Hij schakelt een developer in, voor € 25.000, en een grafisch ontwerpster. Bij de lancering schrijven veel mensen zich in. Maar er ontbreken functionaliteiten die zij essentieel vinden. Het geld is op, wat de app opbrengt dekt de kosten niet, en hij zet hem on hold.

Dit verhaal zegt niets over de kwaliteit van het geleverde werk. Het zegt iets anders. Het budget lag al vast voor een lijst met functionaliteiten, nog voordat er ook maar één reactie van een gebruiker was. Wat de gebruikers nodig hadden, ontdekte hij bij de lancering. Toen was er geen geld meer om het te bouwen.

MVP, prototype, proof of concept: wat is het verschil?

Ze lijken op elkaar: klein, snel, vaak onvolledig. Maar ze nemen niet dezelfde twijfel weg.

Het MVP beantwoordt de vraag: verdient dit product het om te bestaan? Wat u ervan overhoudt, is het antwoord.

Het prototype beantwoordt een andere vraag: werkt dit ontwerp zoals we denken? Een schets van een scherm op het whiteboard is er een. Een model dat test hoe een deel van het programma zich onder belasting gedraagt, is er nog een. Dat laatste moet in code van productiekwaliteit worden geschreven, omdat het daarna deel wordt van de codebase. Holub vat het verschil in twee zinnen samen: “A prototype tests a design. An MVP determines if a product is worth building.”

De proof of concept komt nog eerder. Die controleert of een technische keuze waarover nog wordt nagedacht, overeind blijft. Twijfelt u of de database de belasting aankan, dan schrijft u een programma dat niets anders doet dan er gegevens in wegschrijven en ze weer uitlezen. Het resultaat lijkt in niets op de uiteindelijke software.

De spike, ten slotte, komt uit het vocabulaire van Jez Humble en Dave Farley. In Continuous Delivery (p. 425) is het een wegwerpimplementatie van één specifieke requirement, bedoeld om een analyse-, ontwikkel- of testrisico te verkleinen. De code wordt weggegooid. Alleen het antwoord telt.

Het juiste instrument kiezen begint met benoemen waaraan u twijfelt. Twijfel over de waarde vraagt om een MVP. Twijfel over het ontwerp vraagt om een prototype. Twijfel over de technische haalbaarheid vraagt om een proof of concept of een spike.

Wegwerpcode of fundament: de keuze die vóór de eerste regel code valt

Holub beschrijft twee scholen.

De eerste wil het MVP zo snel mogelijk in handen van potentiële klanten krijgen. De code mag rommelig zijn. Het is wegwerpcode, en dat is het woord dat telt. Deze school gokt erop dat het idee mislukt, en geeft dus zo weinig mogelijk uit.

De tweede behandelt het MVP als de kern van een “walking skeleton”: het eerste stuk van een systeem dat daarna in kleine stappen groeit. Zij gokt erop dat het idee werkt. De code moet dus vanaf het begin productiekwaliteit hebben. De scope blijft piepklein, en volgens de ervaring van Holub is goede code sneller gebouwd dan rommelige code.

Beide zijn te verdedigen, ze door elkaar halen niet. “These two approaches cannot coexist”, schrijft Holub. Wie een MVP van slechte kwaliteit tot kern van een systeem maakt, bouwt op een rotte kern waar hij nooit meer vanaf komt.

In zijn stuk van september 2026 neigt hij naar de tweede school. Het MVP in productiecode bouwen, met tests en een degelijke interface, kost volgens hem maar ongeveer een dag extra. En het resultaat dient daarna als walking skeleton.

Dave Farley verkiest een ontwerp dat in kleine stappen evolueert boven big upfront design (video “How To Avoid Big Upfront Design”, kanaal Modern Software Engineering). Wat ons betreft volgt een MVP dat in productiecode is gebouwd die weg: het groeit stap voor stap, in plaats van helemaal vooraf ontworpen te worden.

Wegwerpprototypes worden nu met AI gebouwd

Wat de eerste school met de hand codeerde, maken AI-tools tegenwoordig. U beschrijft de applicatie die u wilt, zonder de code te lezen die de AI schrijft: dat is vibe coding. Holub erkent dat het een plek heeft: bij wegwerpprototypes.

Daar kwam de maker van de app ook bij uit. In 2025 ontdekt hij vibe coding, en hij schat dat het hem twee dagen had gekost, voor € 0. Op één punt komt zijn rekensom overeen met die van Holub: een test van een paar dagen kan laten zien wat gebruikers missen, voordat het budget op is.

Maar wegwerpcode blijft wegwerpcode. Het met vibe coding gebouwde prototype beantwoordt de vraag over het idee. Het wordt niet het fundament van de software die volgt. Wat “het werkt” niet garandeert, leggen we uit in ons artikel over een app maken met AI.

Na de test: dezelfde vraag, bij elke functionaliteit

Een MVP dat slaagt, rondt niets af. Holub beschrijft wat er volgt. U zet het kleinste wat mogelijk is live. De reactie is bijna altijd: mooi, maar… Dat “maar” wijst de volgende kleinste wijziging aan. U voert die door, zet hem live, en begint opnieuw. Hij voegt eraan toe: geen grote specificatie vooraf, ook niet als een AI die krijgt.

Deze lus stopt niet bij de lancering. In onze adaptieve aanpak is elke functionaliteit een hypothese die we toetsen aan de praktijk van uw gebruikers.

Wij ontwikkelen uw applicatie op maat tegen een vast budget, aan het einde van elke maand gefactureerd voor het geleverde werk. Ze is binnen een maand bruikbaar. Bruikbaar betekent niet af: uw teams gebruiken haar vanaf de eerste maand, en dat gebruik bepaalt wat we de maand erna ontwikkelen.

Waarom niet alles vanaf het begin vastleggen, de lijst met functionaliteiten en de planning? Die vraag stelt ons artikel over de voorspellende en de adaptieve aanpak.

Verder lezen

Onze gids behandelt de experimenten van Kohavi uitgebreid, en wat de functionaliteiten die niemand gebruikt daarna kosten.

Hebt u een idee om te testen, of software die u wilt laten ontwikkelen? Zullen we kennismaken?

Bronnen

Lees ook