MVP Requirements Document Template: de scope die live gaat
Een goed MVP requirements document is geen feature-backlog. Gebruik deze template om leerdoel, scope en briefing voor een leverbare build vast te leggen.
Een MVP requirements document template moet bepalen wat de eerste versie moet bewijzen, niet alles wat het product ooit kan worden. Bij webvise behandelen we het als een leercontract: een gebruiker, een workflow, een succesmetric en een harde out-of-scope-lijst.
Als uw document leest als een feature-backlog, is uw MVP al te groot.
Founders kennen het product meestal beter dan de builder, maar briefen vaak het verkeerde artefact. Deze gids geeft u de template die wij willen zien voor een vaste-prijs MVP build, met voorbeelden en snedes die voorkomen dat een build van 3 tot 5 weken een kwartaalrewrite wordt.
Het document moet leren kopen, geen volledigheid. Als een veld niet helpt om de commerciële aanname te bewijzen, schrapt u het.
Een workflow is genoeg voor versie een. Meer workflows betekenen meer toestanden, meer tests en een tragere lancering.
De out-of-scope-lijst beschermt het budget. Een feature is pas geschrapt wanneer iedereen kan zien waar die heen is gegaan.
De builder heeft beslissingen nodig, geen essays. Noem gebruiker, event, data, owner en launch-metric.
Een goede MVP briefing past op 2 pagina's. Het harde werk is kiezen wat u niet opschrijft.
De template is een leercontract
Een normale PRD legt een product uit. Een MVP requirements document legt een test uit. De eerste regel moet de risicovolle aanname noemen die het product het bouwen waard maakt.
Dat verschil verandert de scope. Een productdocument verzamelt mogelijkheden, terwijl een MVP document een ja-of-nee-besluit afdwingt over wat echte gebruikers moeten doen voordat de volgende investering logisch is.
webvise MVP builds starten bij €5,000 omdat we de eerste release rond het leerdoel scopen, niet rond een droombacklog. Als uw eerste versie auth, een kernworkflow, een database, deployment en analytics nodig heeft, hoort die in een build van 3 tot 5 weken. Als die vijf gebruikersrollen en drie dashboards nodig heeft, is het niet langer de eerste test.
Kopieer deze MVP requirements document template
Gebruik dit als briefing van twee pagina's voordat u een offerte vraagt. Hoe scherper het antwoord, hoe makkelijker een serieuze builder het werk kan prijzen zonder onzekerheid in de raming te stoppen.
| Sectie | Wat u schrijft | Slaagtest |
|---|---|---|
| Risicovolle aanname | De commerciële overtuiging die deze versie moet bewijzen | Als die onjuist is, verandert of stopt u het product |
| Primaire gebruiker | Een benoemd gebruikerstype, geen marktsegment | Een builder kan zich de persoon voorstellen die het product gebruikt |
| Kernworkflow | De stappen van eerste actie tot waarde | Een onbekende kan de workflow testen |
| Succesmetric | Een getal dat beslist of versie een werkte | De metric is zichtbaar binnen 30 dagen na lancering |
| Out of scope | Verleidelijke features die uitgesloten zijn | Elke stakeholder wijst naar dezelfde snedes |
| Data en integraties | Systemen, bestanden, APIs, betalingen, e-mail, auth | Geen verborgen afhankelijkheid verschijnt in buildweek twee |
| Launchbeperking | Budget, timing, juridisch, device, browser, taal | De beperking kan scope blokkeren voordat code start |
| Besliseigenaar | De persoon die snedes mag accepteren | De builder bemiddelt niet elk intern debat |
Verstop onzekerheid niet. Als u de metric nog niet kent, schrijft u de dichtstbijzijnde proxy en markeert u die als voorlopig. Een ontbrekende beslissing in het document wordt tijdens de build een meeting.
Werktitel: een zin die zegt wat het product doet.
Primaire gebruiker: de eerste gebruiker die u werft, niet elke mogelijke koper.
Kernworkflow: 5 tot 10 stappen van instap tot waarde.
Launch-metric: het getal dat u in de eerste 30 dagen kunt meten.
Benodigde systemen: Stripe, Resend, CRM, spreadsheet, CMS of interne API.
Out-of-scope-lijst: elke feature die u nu bewust niet bouwt.
Acceptatieregel: wie tekent af wanneer de build overeenkomt met de briefing.
Als u een buildpartner wilt die dat document uitdaagt voordat code start, bevat webvise's MVP development service product scoping, featureprioriteit, UI design, full-stack development, deployment en basisanalytics.
Schrap features met de vijfvragenpoort
De meeste scopeconflicten ontstaan omdat elke feature los bekeken redelijk klinkt. De poort lost dat op. Een feature blijft alleen in de MVP als die alle vijf vragen overleeft.
| Vraag | Houden wanneer | Schrappen wanneer |
|---|---|---|
| Bewijst het de risicovolle aanname? | Het antwoord verandert de volgende funding-, sales- of buildbeslissing | Het laat het product alleen completer voelen |
| Heeft de eerste gebruiker het nodig? | De primaire gebruiker bereikt zonder dit geen waarde | Een later gebruikerstype zou het graag willen |
| Is het binnen 30 dagen meetbaar? | Gebruiks-, betalings-, voltooiings- of antwoorddata verschijnt snel | Het signaal heeft een groot publiek nodig dat u nog niet heeft |
| Vermindert het operationeel risico? | Het voorkomt fraude, dataverlies, supportfalen of juridische blootstelling | Het bestaat omdat een concurrent het heeft |
| Kan een mens dit handmatig doen in versie een? | Handwerk zou de belofte breken of onveilige dataverwerking veroorzaken | Handwerk is vervelend maar acceptabel voor de eerste tien gebruikers |
De handwerkvraag bespaart echt geld. Veel founders bouwen adminschermen, billingrandgevallen en notificatiecentra voordat ze weten of iemand het product twee keer gebruikt.
Mini-story: OHYP had een output die telde
Op 2026-02-20 publiceerden we de OHYP GmbH case study, een vastgoedservice uit Berlin die financieringsverklaringen nodig had voor woningkopers. Het product begon niet als generiek fintech-platform. Het begon met een output: een koper moest binnen 24 uur een bindend certificaat ontvangen, zonder SCHUFA-kredietonderzoek, terwijl het systeem meer dan 550 partnerbanken vergeleek.
Die output maakte de MVP scope helder. We bouwden een financieringsformulier in 10 stappen, geautomatiseerde PDF-certificaatgeneratie en een admin dashboard voor de aanvraagcyclus. De build ging live in 6 weken met Next.js, React, tRPC, TypeScript, PostgreSQL, Drizzle ORM, Tailwind CSS en Vercel.
| Scopebeslissing | OHYP voorbeeld | Waarom het bleef |
|---|---|---|
| Primaire gebruiker | Woningkoper in Duitsland | De certificaatworkflow begint met deze gebruiker |
| Kernworkflow | Financieringsformulier in 10 stappen | Het verzamelt de data voor een geldig certificaat |
| Succesoutput | Certificaat binnen 24 uur | De bedrijfsbelofte hangt af van doorlooptijd |
| Data-afhankelijkheid | Meer dan 550 partnerbanken | Het product kan de belofte zonder vergelijking niet waarmaken |
| Adminbehoefte | Dashboard voor de aanvraagcyclus | Het team had na inzending controle nodig |
| Performancegrens | 96 Lighthouse, onder 1.2s laadtijd | De funnel moest vertrouwen geven voor invoer van gevoelige data |
De les is niet dat elke MVP een formulier in 10 stappen nodig heeft. De les is dat één scherpe output tien stappen kleiner laat voelen dan vijf vage features.
Mini-story: vibe-coded MVPs falen bij de handoff
Lovable, Bolt en v0 zijn nuttig voor prototypes omdat ze de tijd tussen idee en publieke URL verkorten. De mislukking begint wanneer dat prototype MVP wordt genoemd en een betalende klant krijgt voordat iemand auth, datatoegang, adminworkflows of observability bezit.
In onze vibe-coded MVP teardown schreven we de regel op die we gebruiken wanneer founders zulke codebases brengen: we bouwen opnieuw vanaf nul. Een schone build op onze stack duurt 3 tot 6 weken. Salvage duurt 8 tot 12 weken omdat elke fix rekening moet houden met een schema, routestructuur en live datamodel die niemand heeft ontworpen.
Daarom moet het requirements document de handoff-oppervlakte bevatten. Als een klant betaalt, heeft de MVP vanaf dag één een echt datamodel, sessieregels, adminacties en monitoring nodig. Als het document alleen login, dashboard en AI feature zegt, vult de builder de riskantste delen zonder uw input in.
Zo geeft u het document aan een agency
Stuur het document vóór de eerste raming en beoordeel de agency op de vragen die ze stelt. Een goede builder schrapt, daagt uit en ordent de scope. Een zwakke builder accepteert elke feature en verstopt de kosten in een grotere offerte.
Budgetband: zeg of dit een beslissing van €5,000, €15,000 of €50,000 is voordat de scope groeit.
Timeline: noem de lanceerdatum en waarom die telt.
Bestaand bewijs: voeg waitlistcijfers, interviews, prototypelinks, betaalde intentiebrieven of handmatige workflowdata toe.
Benodigde accounts: lijst Stripe, Vercel, Supabase, PostHog, CRM, e-mail en domeintoegang vóór kickoff.
Harde nee-lijst: zeg wat niet mag gebeuren, zoals medische data opslaan, een no-code backend gebruiken of lanceren zonder audit logs.
Cut owner: noem de persoon die binnen 24 uur een feature kan verwijderen.
Ter context: webvise bouwt MVPs met Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel, CI/CD, analytics en deployment in de eerste scope. Die stack is niet het punt. Het punt is dat de MVP schoon genoeg moet zijn om te groeien wanneer de test werkt.
De laatste test voordat u verzendt
Lees elke regel en vraag of die de builder helpt een scopebeslissing te nemen. Als de regel niet verandert wat gebouwd, gemeten, geschrapt of uitgesteld wordt, verwijdert u hem.
| Zwakke regel | Herschrijf als | Waarom het werkt |
|---|---|---|
| Gebruikers kunnen hun profiel beheren | Kopers kunnen naam, e-mail, telefoon en financieringsbedrag bewerken vóór certificaatgeneratie | Het noemt gebruiker, velden en workflow |
| Admin dashboard | Staff kan nieuwe certificaataanvragen zien, status wijzigen en de gegenereerde PDF downloaden | Het benoemt de echte admintaak |
| AI aanbevelingen | Het systeem markeert ontbrekende financieringsdata vóór inzending eerst met vaste validatieregels | Het vermijdt vage AI scope tot de regel bekend is |
| Betalingen later | Stripe is out of scope voor versie een tenzij een betaalde pilot vóór kickoff is getekend | Het maakt van een toekomstidee een trigger |
| Mobile friendly | Het formulier in 10 stappen moet bruikbaar zijn op een telefoon van 390px breed vóór desktoppolish | Het maakt de devicebeperking testbaar |
Een kort MVP requirements document voelt ongemakkelijk omdat het de echte beslissing blootlegt. Dat is het punt. Het document moet duidelijk maken waarop u wedt, wat u weigert te bouwen en welk resultaat de volgende versie rechtvaardigt.
webvise helpt founders om die beslissing om te zetten in een geleverde eerste versie, niet in een opgeblazen featurelijst. Als uw MVP briefing dichtbij is maar nog te breed, stuur hem naar webvise en we vertellen wat we vóór buildweek één zouden schrappen.