Wat u moet beslissen voordat u een MVP bouwt

Een MVP is geen kleinere versie van elk idee op uw roadmap. Het is het kleinste bruikbare product waarmee een omschreven groep mensen een belangrijke workflow kan afronden en dat het team bewijs geeft voor de volgende beslissing.

Bij dat woord — bewijs — is het de moeite waard even stil te staan.

De analyse van CB Insights over waarom start-ups mislukken (opent in een nieuw tabblad), gepubliceerd in maart 2026, onderzocht 431 door durfkapitaal gefinancierde bedrijven die sinds 2023 publiek zijn gestopt. Ze vond in 70 % van de gevallen dat het kapitaal opraakte en in 43 % een slechte product-marktcombinatie.

De nuttigere observatie gaat over wanneer die combinatie misgaat: „twee derde van de mislukkingen op product-marktcombinatie waren bedrijven in een vroege fase die nooit een markt vonden”.

Geld is hoe het eindigt. Niet snel genoeg leren is vaak waarom. Hetzelfde principe geldt voor een intern bedrijfsmiddel: de eerste release moet aantonen dat één belangrijke workflow beter werkt.

De eerste release is dus geen demonstratie van uw ambitie. Het is een instrument om iets te weten te komen. De beslissingen hieronder bepalen of het dat kan.

Wat een MVP niet is

Drie misvattingen richten de meeste schade aan, en het loont ze te benoemen voordat het plannen begint:

• Een goedkopere versie van het volledige product. Overal de kwaliteit verlagen laat je achter met iets wat niemand kan beoordelen. Snijd in plaats daarvan in de scope, en bouw wat overblijft goed.
• Een prototype. Een prototype beantwoordt een ontwerpvraag en wordt daarna weggegooid. Een MVP is echte software met echte gebruikers, en moet te onderhouden zijn.
• Een definitieve architectuur. De eerste release moet kunnen veranderen. Beslissingen die duur zijn om terug te draaien, verdienen meer nadenken dan beslissingen die dat niet zijn.

De nuttige vraag is niet „wat is het minste dat we kunnen bouwen?” Maar: „wat is het minste dat we kunnen bouwen dat ons nog steeds iets leert waarnaar we zouden handelen?”

Moet u eigenlijk wel maatwerk bouwen?

Voordat u een maatwerkbouw afbakent, loont het te vragen of u die al nodig hebt.

Maatwerksoftware is het juiste antwoord wanneer uw workflow echt specifiek is, wanneer u het resultaat in eigendom moet hebben, of wanneer standaardtools niet kunnen aansluiten op de manier waarop uw bedrijf werkt.

Het is vaak het verkeerde eerste antwoord wanneer een no-codetool, een spreadsheet of een bestaand product u deze week dezelfde aanname zou laten toetsen.

Een bruikbare volgorde is de vraag valideren met het goedkoopste dat werkt, en daarna maatwerk bouwen zodra u weet welke delen dat echt nodig hebben.

Veel succesvolle producten beginnen als een handmatig proces of een samengesteld pakket tools. Ze worden pas maatwerksoftware daar waar dat samenstel begint te knellen.

Te vroeg maatwerk bouwen besteedt uw budget aan het bewijzen van iets wat een veel goedkopere test u had kunnen vertellen. Te laat bouwen laat u vechten met tools die niet meer passen.

Beantwoord dat eerlijk voordat je begint met scopen, niet erna.

Begin bij de workflow van de gebruiker

Beschrijf, vóórdat je over techniek praat, wie het product gaat gebruiken, in welke situatie diegene zit en welke taak af moet. Blijft dat vaag, dan volgt die vaagheid je naar elk scherm en elke functie.

Schrijf de hoofdworkflow op als een korte reeks. Bijvoorbeeld: een klant dient een verzoek in, een teamlid beoordeelt het, het systeem legt de beslissing vast, en beide kanten zien de volgende stap.

De Britse Government Digital Service formaliseert dit als een discoveryfase. Het servicehandboek (opent in een nieuw tabblad) is onomwonden over de volgorde: „voordat u zich vastlegt op het bouwen van een dienst, moet u het probleem begrijpen dat opgelost moet worden”.

Het noemt ongeveer vier tot acht weken als gebruikelijk voor die discovery, eindigend in een expliciete beslissing of er überhaupt een levensvatbare dienst bestaat.

Een kort, afgebakend onderzoek met een echte go/no-go is goedkoper dan een bouw die in maand vijf hetzelfde ontdekt.

Bepaal wat binnen de scope hoort

Splits daarna het must-have werk van het later-nuttige werk. Inloggen, rechten, betalingen, meldingen, rapportage, koppelingen en beheertools kunnen allemaal belangrijk zijn, maar de eerste release hoeft ze niet allemaal even ver uitgewerkt te hebben.

Een goede scope heeft voor elke functie een reden. Houd een functie in de eerste release wanneer die minstens één van deze toetsen doorstaat:

1. de eerste gebruiker kan de kernworkflow zonder die functie niet afronden
2. ze verkleint een leveringsrisico dat u al hebt vastgesteld
3. het geeft het team vanaf dag één de controle die het nodig heeft
4. weglaten zou een herbouw afdwingen in plaats van een toevoeging

Doorstaat een functie geen van deze toetsen, dan is het een latere beslissing en geen schrapping. Het zo vastleggen ontmantelt meestal de discussie over weghalen.

Beslis hoe u weet dat het werkte

Spreek voordat de bouw begint af welk resultaat doorgaan, koerswijziging of stoppen zou rechtvaardigen. Zonder dat leest elke uitkomst als bemoedigend.

Kies signalen die u in de eerste weken van echt gebruik kunt waarnemen, niet signalen die een jaar aan data vragen:

• mensen ronden de kernworkflow af zonder dat ze erdoorheen worden geleid
• ze komen terug zonder dat ze eraan worden herinnerd
• het handwerk dat het product verving, gaat duidelijk omlaag
• iemand vraagt om de volgende functie in plaats van om een basisfix

Schrijf op wat u verwacht te zien en wanneer. Dat vergelijken met wat er gebeurt, is precies het punt van vroeg uitbrengen.

Schrijf op wat „klaar” betekent

Bepaal wat „werkt” betekent voordat de ontwikkeling begint. Gebruik waarneembare acceptatiecriteria zoals: de gebruiker kan een verzoek indienen, de juiste persoon kan het beoordelen, en het systeem legt het resultaat correct vast.

De GDS-richtlijn over het schrijven van user stories (opent in een nieuw tabblad) beschrijft acceptatiecriteria als „een lijst uitkomsten die u als checklist gebruikt om te bevestigen dat uw dienst zijn werk heeft gedaan”, elk in de vorm het is klaar wanneer… opgeschreven.

De waarde zit erin dat iemand die het niet gebouwd heeft ze kan controleren.

Op releaseniveau definieert The Scrum Guide (opent in een nieuw tabblad) de Definition of Done als „een formele beschrijving van de staat van het increment wanneer het voldoet aan de kwaliteitsmaatstaven die voor het product vereist zijn”.

Of u nu Scrum doet of niet, het idee reist mee. Een afgesproken, opgeschreven kwaliteitslat voorkomt dat „af” voor iedereen in het gesprek iets anders betekent.

Leg dataregels vast vóór het schema

Beslis welke informatie het product moet opslaan en wie erbij mag. Privacy, rechten, bewaring, back-ups en auditbehoeften zijn makkelijker te plannen voordat de eerste databasetabellen en koppelingen er zijn.

Voor producten die persoonsgegevens van mensen in de EU verwerken, is die volgorde de wet en geen voorkeur.

De richtsnoeren van de Europese Commissie over gegevensbescherming door ontwerp en door standaardinstellingen (opent in een nieuw tabblad) beschrijven maatregelen die aangrijpen in de vroegste fasen van het ontwerp van de verwerking, met standaardinstellingen zo gezet dat „persoonsgegevens worden verwerkt met de hoogste privacybescherming”.

Het Europees Comité voor gegevensbescherming heeft aparte richtsnoeren over artikel 25 (opent in een nieuw tabblad) in oktober 2020 in definitieve vorm aangenomen, mocht u het uitgewerkte standpunt van de toezichthouder nodig hebben.

In de praktijk is dit een korte lijst om op te schrijven: wat u verzamelt, waarom, wie het mag zien, hoe lang u het bewaart en hoe iemand het laat verwijderen.

Die vragen beantwoorden vóór het ontwerp van de database kost veel minder dan ze er later in bouwen.

Kies technologie en AI met zorg

Kies technologie rond het product en zijn randvoorwaarden. Een modern framework kan goed passen, maar de betere keuze hangt af van de gebruikers, de data, de koppelingen, de leveringsbehoeften en de mensen die de software gaan onderhouden.

AI verdient dezelfde discipline. Beslis of het de kernworkflow ondersteunt, wat er gebeurt wanneer de uitvoer fout is, en hoe iemand die kan nakijken of corrigeren, voordat u het als productvereiste behandelt.

Er is nu gemeten reden tot voorzichtigheid. Het 2025 DORA report (opent in een nieuw tabblad), gebaseerd op antwoorden van bijna 5.000 technologieprofessionals, meldt dat „AI-adoptie nog steeds een negatieve relatie heeft met de stabiliteit van softwarelevering”.

Sneller produceren zonder stevig testen en reviewen telt niet op tot sneller leveren. Het telt op tot herstelwerk.

Plan reviews, toegang en overdracht

Plan de reviewmomenten vóór de eerste regel code. Korte demo’s, een gedeelde takenlijst en besluiten die zichtbaar zijn vastgelegd, laten je bijsturen zolang bijsturen nog goedkoop is.

Het US Government Accountability Office maakt het risicoargument in zijn Agile Assessment Guide (opent in een nieuw tabblad): incrementeel leveren met doorlopende evaluatie «kan de risico's verkleinen van het financieren van een programma dat mislukt of verouderde technologie oplevert».

Spreek eigendom en toegang vanaf het begin af. Het project hoort een duidelijke coderepository te hebben, gedocumenteerde omgevingen, een afgesproken uitrolpad en een overdrachtsplan dat niet afhangt van het privéaccount van één persoon.

De DORA-capability versiebeheer (opent in een nieuw tabblad) is concreet over wat daarin hoort: applicatiecode en afhankelijkheden, tools om omgevingen te maken, containercompositiebestanden, cloudconfiguratie en AI-artefacten zoals prompts.

De opgegeven grond is dat „onderzoek consistent laat zien dat volledig gebruik van versiebeheer continue levering voorspelt”.

De GDS-richtlijn over versiebeheer (opent in een nieuw tabblad) voegt de andere helft van de regel toe, de review: „elke codewijziging wordt beoordeeld door iemand die haar niet heeft geschreven”.

Samen maken die gewoonten een overdracht mogelijk. Als het herbouwen van het systeem afhangt van iemands laptop, hebt u geen op te leveren product — u hebt een afhankelijkheid.

Plan de doorlooptijd en het budget

Een scherp afgebakende MVP is vaak te plannen rond een leveringsvenster van 6–8 weken wanneer de scope die vorm heeft. Dat is een planningsreferentie, geen universele belofte; koppelingen, goedkeuringen en onbekende legacysystemen kunnen de doorlooptijd veranderen.

Het helpt te weten hoe softwareplanningen misgaan, want ze gaan niet even hard mis in beide richtingen.

Een studie van 5.392 IT-projecten gepubliceerd in het Journal of Management Information Systems (opent in een nieuw tabblad) vond dat kostenoverschrijdingen een machtswet volgen in plaats van een normale verdeling.

De meeste overschrijdingen zijn bescheiden, maar er is „een dikke staart met een kleiner aantal projecten met extreme overschrijdingen”. Plannen op het gemiddelde onderschat juist het risico dat ertoe doet.

Dit is niet alleen een start-upprobleem. De hoogrisicobeoordeling van de federale IT door het GAO (opent in een nieuw tabblad), gepubliceerd in januari 2025, legt vast dat federale IT-investeringen „te vaak mislukken of kostenoverschrijdingen en vertragingen oplopen terwijl ze weinig bijdragen aan missiegerelateerde resultaten”.

En dat bij een jaarlijkse uitgave van meer dan 100 miljard dollar. Schaal en budget lossen dit niet op; scopediscipline en korte feedbacklussen wel.

Begroot beslissingen, niet alleen codeeruren. Verkenning, ontwerp, bouw, testen, uitrol, content, diensten van derden en de correcties na de lancering tellen allemaal op bij wat nodig is om de eerste release bruikbaar te maken.

Een uitgewerkt voorbeeld

Neem een oprichter die een boekingsplatform wil: klanten boeken afspraken, aanbieders beheren agenda's, beide kanten betalen en krijgen herinneringen, en een beheerder houdt overzicht. Het is een echt product met een lange functielijst.

De kernworkflow is echter smal — een klant vindt een vrij tijdslot en boekt het, en de aanbieder ziet de boeking. Al het andere ondersteunt dat of kan wachten.

Een gedisciplineerde eerste release zou er zo uit kunnen zien:

• Binnen scope: beschikbaarheid van de aanbieder, boeking door de klant, een bevestiging en een eenvoudig overzicht van komende boekingen voor de aanbieder.
• Uitgesteld: betalingen in de app (eerst handmatig een aanbetaling innen), automatische herinneringen, beoordelingen, zoeken over meerdere aanbieders en het beheerdashboard.
• Vooraf beslist: welke klantgegevens worden opgeslagen en hoe lang, van wie de repository is, en wat „een boeking werkte” als acceptatiecriterium betekent.

De uitgestelde lijst is niet opgegeven — het is de roadmap. Maar de kern eerst uitbrengen beantwoordt de enige vraag die vroeg telt: houden aanbieders hun agenda's bij, en gaan klanten boeken?

Zo ja, dan is de rest het bouwen waard. Zo nee, dan had geen enkele betaalkoppeling het gered.

Aan de slag

Het doel is niet alles voorspellen. Het doel is de belangrijke aannames zichtbaar maken, de kernworkflow toetsen en een productfundament leggen dat verbeterd kan worden zonder het werk weg te gooien.

Hebt u een idee maar geen volledige specificatie, begin dan bij de gebruiker, de workflow en de beslissing die de eerste release moet ondersteunen. Die drie punten zijn genoeg om een nuttig planningsgesprek te beginnen.