Product

Wat een MVP is, en wanneer je er een nodig hebt

De term wordt gebruikt voor alles tussen een schets en een half product. Wat het echt betekent, en wanneer het juist niet de goede aanpak is.

Gepubliceerd 8 augustus 2026

MVP is een van de meest versleten woorden in softwareland. Het wordt gebruikt voor een schets, voor een demo, en vaak gewoon voor een product dat niet af is. Dat is jammer, want het oorspronkelijke idee is nuttig: de kleinste versie waarmee je een echte vraag beantwoordt.

Minimum slaat op de vraag, niet op de kwaliteit

Het misverstand zit in het woord minimum. Dat gaat over hoeveel functies je bouwt, niet over hoe goed je ze bouwt. Een MVP die omvalt, traag is of gegevens kwijtraakt, beantwoordt geen enkele vraag: gebruikers haken af om de kwaliteit en je leert niets over het idee. Klein in omvang, normaal in degelijkheid.

Eerst de vraag, dan de bouw

Voordat er iets gebouwd wordt, hoort er een zin op papier te staan die begint met: we denken dat. Bijvoorbeeld: we denken dat installateurs zelf offertes willen samenstellen als ze staffelprijzen direct zien. Die zin bepaalt wat er in versie één moet, en belangrijker, wat eruit kan. Zonder die zin bouw je alles wat iemand bedacht heeft en weet je achteraf nog steeds niets.

Wanneer een MVP niet de goede aanpak is

Als je het antwoord al weet. Vervang je een proces dat aantoonbaar werkt maar handmatig is, dan is er niets te valideren. Bouw het gewoon goed.
Als het niet half kan. Bij financiële verwerking, medische gegevens of veiligheid is een uitgeklede versie geen experiment maar een risico.
Als je maar één keer kunt lanceren. Heb je één kans bij een grote klant of één beursmoment, dan is een halve indruk erger dan wachten.
Als de organisatie het niet als experiment behandelt. Zodra de eerste versie live staat, gaat iedereen ermee werken en is er geen budget meer voor versie twee. Dat is een kwestie van verwachtingen, niet van techniek.

Bouw de fundering wel meteen goed

Er zit een verschil tussen weinig functies en slecht gebouwd. De datamodellen, de architectuur en de manier waarop gegevens worden opgeslagen moeten vanaf het begin kloppen, ook als de eerste versie klein is. Dat kost nauwelijks extra tijd en scheelt maanden als het aanslaat. Wat je wel weglaat: alles wat pas nodig is bij schaal die je nog niet hebt.

Spreek vooraf af wat succes is

De vraag na de lancering is altijd: gaan we door? Zonder afspraak vooraf wordt dat een gevoelskwestie en wint de hardste stem. Leg vast waar je op stuurt en wat de ondergrens is. Hoeveel mensen gebruiken het, hoe vaak, en waarvoor. Ook als het antwoord nee is, heb je dan iets geleerd voor een fractie van de kosten.

Veelgestelde vragen

Wat is het verschil met een prototype?

Een prototype laat zien hoe iets zou werken, meestal zonder echte werking eronder: klikbare schermen om een idee te toetsen. Een MVP werkt echt en wordt door echte gebruikers voor echt werk gebruikt. Een prototype toetst of mensen het begrijpen, een MVP of ze het gebruiken.

Hoe lang duurt een MVP?

Bij een scherp afgebakende vraag zijn het weken, geen maanden. Loopt het uit, dan is dat bijna altijd omdat de scope groeit tijdens het bouwen. Dat is het signaal om terug te gaan naar die ene zin die begint met: we denken dat.

Kunnen we erop doorbouwen als het aanslaat?

Ja, mits de fundering vanaf het begin klopt. Dat is precies waarom wij die wel meteen goed neerzetten. Een eerste versie die je moet weggooien is duurder dan hij lijkt, want je betaalt hem twee keer.

Moeten we het aan klanten laten zien of intern houden?

Aan echte gebruikers laten zien, anders meet je niets. Wel bij een beperkte groep die weet dat het een eerste versie is. Collega's zijn geen goede testers: zij zijn te aardig en kennen de bedoeling al.

Verder lezen

Plan een kennismaking