Een MVP, oftewel minimum viable product (minimaal levensvatbaar product), is de kleinste versie van een product waarmee je de belangrijkste aanname bij echte gebruikers kunt toetsen. Het gaat niet om een "goedkope versie van de app", maar om de kortste weg naar het antwoord op één vraag: heeft iemand dit echt nodig en doet die persoon wat je verwacht?
Kom je hier vanuit games of sport? Daar betekent MVP "most valuable player", de beste speler. In dit artikel gaat het om het product.
Waar de term vandaan komt
De term kwam begin jaren 2000 op en werd bekend dankzij Steve Blank en Eric Ries. In "The Lean Startup" beschrijft Ries de MVP als de versie van een product waarmee je met zo min mogelijk moeite zo veel mogelijk gevalideerde kennis over klanten verzamelt. Twee woorden zijn hier belangrijk: kennis en moeite. Een MVP moet iets leren, niet alleen bestaan.
Wat de drie letters betekenen
- Minimum — alleen wat nodig is om één aanname te toetsen. Elke extra functie verlengt de tijd tot het eerste antwoord.
- Viable — het product moet echt werken en waarde leveren. Een wankel prototype vertelt je niet of mensen de oplossing willen, alleen dat ze niets kapots willen.
- Product — iets wat mensen gebruiken of waarvoor ze betalen. Een enquête "zou je het kopen?" is onderzoek, geen product.
De meest gemaakte fout is alleen de eerste letter onthouden. "Minimum" zonder "viable" levert een product op dat niets bewijst.
Soorten MVP
Niet elke MVP is een app. Je begint met de goedkoopste manier die een betrouwbaar antwoord geeft.
Een pagina om je in te schrijven (smoke test). Je beschrijft het product alsof het al bestaat en meet hoeveel mensen hun e-mailadres achterlaten of op "kopen" klikken. Zo toets je de vraag nog voordat er een regel productcode bestaat.
Concierge-MVP. Je voert de dienst met de hand uit voor de eerste klanten. Je weet meteen waarvoor ze betalen en wat voor hen telt, en pas daarna automatiseer je.
"Tovenaar van Oz"-MVP. De klant ziet een kant-en-klaar product, maar achter de schermen doet een mens een deel van het werk. Je kijkt of mensen de oplossing gebruiken voordat je dure automatisering bouwt.
Product met één functie. Een werkende app die één ding goed doet: bijvoorbeeld alleen reserveren, zonder loyaliteitsprogramma, chat en rapporten. Dit is de meest voorkomende vorm als de aanname gaat over de vraag of mensen het regelmatig zullen gebruiken.
MVP van kant-en-klare bouwstenen. Een formulier, een spreadsheet, een betaaltool en automatisering in plaats van een eigen systeem. Snel en goedkoop, maar met grenzen zodra het verkeer groeit.
Bekende voorbeelden
- Dropbox liet, voordat het het volledige product bouwde, een korte video zien over hoe het synchroniseren van bestanden zou werken. De wachtlijst groeide in één nacht van een paar naar enkele tienduizenden mensen. Dat was een test van de vraag, geen app.
- Zappos had in het begin geen magazijn. De oprichter fotografeerde schoenen in lokale winkels en kocht ze na een bestelling om ze te versturen. Hij toetste of mensen schoenen online zouden kopen.
- Airbnb begon met het verhuren van luchtbedden in het appartement van de oprichters tijdens een conferentie in San Francisco, toen de hotels vol zaten. Een simpele site, een paar gasten, echt geld.
In alle drie de gevallen toetste de eerste versie één aanname waar het hele idee van afhing.
Wat een MVP niet is
Het is geen prototype om aan investeerders te laten zien. Een prototype toetst of de oplossing te begrijpen en te bedienen is. Een MVP toetst of mensen het gebruiken of ervoor betalen. Beide zijn nuttig, maar ze beantwoorden verschillende vragen.
Het is niet een eerste versie met de helft van de functies. Als de functielijst van de MVP eruitziet als een jaarplan in tweeën gedeeld, is het geen MVP. Het is een volledig product dat langzamer wordt gebouwd.
Het is geen half werk. Een smalle scope is geen excuus voor fouten, traagheid of onveilige opslag van gegevens. Weinig functies, maar goed gemaakt.
Het is niet het einde van het werk. De MVP is het begin van een leercyclus. Daarna komen data, beslissingen en volgende versies.
Hoe je de scope van de MVP kiest
- Schrijf je aannames op. Wie heeft het probleem, hoe lost die persoon het nu op, wat kost dat, waarom zou die jou kiezen.
- Kies de riskantste. Die waarvan de rest vervalt als ze onwaar blijkt. Meestal gaat het erom of het probleem pijnlijk genoeg is, niet of het technisch op te lossen is.
- Bepaal wat je als succes ziet. Concreet en vóór de start: bijvoorbeeld "10 van de 50 mensen op de lijst betalen voor de eerste maand". Zonder dat kun je elk resultaat in je eigen voordeel uitleggen.
- Schrap al het andere. Inloggen via vijf diensten, een dashboard met rapporten, een app voor twee systemen: als het niet helpt om die ene aanname te toetsen, kan het wachten.
Meer over hoe je zo'n cyclus stap voor stap doorloopt, schrijf ik in het onderwerp over de lean startup methode, en over het ordenen van aannames op één blad bij de lean canvas.
Wat een MVP kost en hoe lang het duurt
Dat hangt af van het soort. Een pagina om je in te schrijven of een concierge-MVP kan in een paar dagen klaar zijn en kost weinig. Een werkende webapp met één hoofdfunctie, inloggen en betalingen is meestal een kwestie van enkele weken werk.
Bij mij kost een MVP van een webapp met een smalle scope 1 900–9 300 € tegen een vaste prijs en duurt het 2 tot 6 weken. Waar die bandbreedte vandaan komt en welke verborgen kosten er zijn, leg ik uit in het artikel Kosten van een MVP in 2026. Wil je beginnen? Bekijk dan hoe ik een MVP bouw.
Veelgestelde vragen
Moet een MVP een app zijn? Nee. Als de belangrijkste vraag is "wil iemand dit?", volstaan een pagina, gesprekken en een met de hand uitgevoerde dienst vaak. Een app is de moeite waard als je wilt toetsen of mensen hem regelmatig zullen gebruiken.
Mag je een "onaffe" MVP aan klanten laten zien? Ja, op voorwaarde dat wat hij doet, goed werkt. Vroege gebruikers vergeven ontbrekende functies, maar niet als het basale niet werkt.
Wat komt er na de MVP? Je meet wat mensen hebben gedaan en beslist: doorontwikkelen, van koers veranderen of stoppen. Hoe je merkt dat je product een echte behoefte raakt, lees je in het onderwerp over product-market fit.