Het verwarrende verschil
Drie woorden die in vrijwel elke kickoff-meeting van een nieuwe oplossing langskomen: prototype, MVP, eerste versie. Drie woorden die regelmatig door elkaar gebruikt worden alsof ze synoniemen zijn.
Dat zijn ze niet. En het verschil bepaalt of je over zes weken iets in productie hebt, of dat je over zes maanden nog steeds Figma-screens aan het herzien bent.
Prototype
Een prototype is een hypothese met een gezicht. Het bestaat om vroege vragen te beantwoorden: voelt deze flow logisch? Begrijpen gebruikers het kassasysteem? Is deze interactie haalbaar binnen de tijd?
Een prototype hoeft niet te werken. De data mag fake zijn. De knoppen mogen alleen visueel reageren. Edge cases zijn uitgesloten. Het is een tekenfilm van een product, niet het product zelf.
Snelheid is het hele punt. Een week is veel.
MVP
Een MVP is een product dat live gaat met de minimale set features. Niet "een prototype met data". Een product. Het werkt in productie, het accepteert betalingen als dat hoort, het heeft een database die je niet morgen wegmiet en die je niet hoeft te migreren bij elke iteratie.
Het verschil zit niet in aantal features. Het zit in state-houding. Een MVP kan met één feature live gaan als die feature kerngebruikers iets oplost waarvoor ze willen betalen. Een prototype dat tien features simuleert is nog steeds geen MVP — niemand kan ermee aan de slag.
De vraag waar de meeste projecten op stranden is niet "wat moet erin?". Het is "wat hoort er bewust níet in versie 1?".
Eerste versie (v1.0)
Een eerste versie is een MVP die heeft geleerd. Het is wat ontstaat na de eerste vijftig echte gebruikers, na de eerste support-tickets, na de eerste edge case die niemand had voorzien.
Een MVP en een v1.0 mogen hetzelfde codebestand delen, maar ze hebben verschillende ouders. De MVP is geboren uit hypothesen; v1.0 uit feiten.
De valkuil
De typische valkuil — die ik vaker zie dan iedere andere — is een team dat zegt "we bouwen een MVP" maar in werkelijkheid een prototype-met-database aan het bouwen is. Zes weken bouwen, twee weken QA, één week soft-launch, en als de eerste gebruiker een echte fout meldt blijkt dat:
- Het data-model breekt bij meer dan één tenant
- Auth werkt alleen voor de happy path
- Betalingen zijn nooit in productie getest
- Er staat geen analytics in
- Er is geen rollback-plan
Dat is een prototype dat zich voordoet als een MVP. Het is niet te weinig gedaan — het is het verkeerde gedaan.
Het enige verschil dat er toe doet
Eén vraag, op week twee van bouw: gaat hij live, of niet?
Als het antwoord ja is en je hebt nog tijd over: je bent een MVP aan het bouwen. Knip features eraf zodat het ook echt op je deadline lukt.
Als het antwoord nee is en het project loopt door: je bent een prototype aan het bouwen. Wees daar eerlijk over, en hou de scope kort. Verkleinen is goedkoper dan rebranden.
Bij Thomas Foundry maak ik die check expliciet in week twee. Het zorgt soms voor een ongemakkelijk gesprek. Het zorgt nooit voor een ongemakkelijke launch.