Hoe lang duurt het om een MVP te bouwen? Een praktisch plan van 3 tot 5 weken
Een gefocuste MVP duurt 3 tot 5 weken wanneer die één workflow test met standaard auth, één datamodel en één succesmetric. Dit is de eerlijke planning.
Hoe lang duurt het om een MVP te bouwen? Een gefocuste web-MVP duurt 3 tot 5 weken wanneer die één workflow test met standaard auth, één datamodel en één succesmetric. Het duurt 6 tot 12 weken of langer wanneer de briefing meerdere rollen, zware integraties of goedkeuring door een comité bevat.
Het ongemakkelijke deel is dat de kalender meestal een scopebeslissing is, geen engineeringfeit.
Als u nu offertes vergelijkt, is de spreiding waarschijnlijk verwarrend om een geldige reden. Sommige teams offreren een eerste test, terwijl andere teams een kleine versie van het eindproduct offreren. Deze gids geeft u de planning die wij bij webvise gebruiken, de blokkades die haar verlengen, en de snijregels die voorkomen dat een MVP zich voordoet als een volledige build.
3 tot 5 weken is realistisch voor één kernworkflow. Dat betekent één primaire gebruiker, één taak, één databasestructuur, één launchmetric en snelle beslissingen.
6 tot 12 weken is normaal wanneer de scope meerdere rollen of diepe integraties bevat. Dat is geen mislukking. Het is een grotere eerste release.
De eerste week beslist de planning. Trage accounttoegang, vage acceptatieregels en late API-beslissingen kosten meer tijd dan code.
webvise bouwt MVPs vanaf €5.000 in 3 tot 5 weken wanneer de scope in deze vorm past. De servicespecificatie staat hier: MVP development.
De veiligste MVP is niet de kleinste set functies. Het is het kleinste product dat binnen 30 dagen na launch een beslissing kan opleveren.
Het korte antwoord per scope
Publieke MVP-planninggidsen komen meestal uit tussen 4 en 12 weken. Die bandbreedte is niet fout, maar verbergt de nuttige vraag: over welk soort MVP hebben we het?
Bij webvise splitsen we het antwoord op basis van de scopevorm. De belofte van 3 tot 5 weken hoort bij een web-MVP met een duidelijke workflow, een vaste techstack en een beslisser die tijdens de build functies kan schrappen.
| Scopevorm | Typische planning | Wat het bewijst |
|---|---|---|
| Klikbaar prototype | 2 tot 5 dagen | Begrijpt iemand het aanbod en de flow? |
| No-code test | 1 tot 2 weken | Klikken mensen, schrijven ze zich in of betalen ze voordat software bestaat? |
| Gefocuste web-MVP | 3 tot 5 weken | Kan één gebruiker de kernworkflow met echte data afronden? |
| Standaard product-MVP | 6 tot 12 weken | Kunnen meerdere rollen het product met echte integraties gebruiken? |
| Gereguleerde of marketplace-MVP | 12+ weken | Kan het product risico, rechten, compliance of tweezijdige vraag dragen? |
Als uw idee eerst een landingspagina, wachtlijst en handmatige opvolging nodig heeft, betaal dan nog niet voor een MVP. Als het auth, één workflow, een database, deployment en analytics nodig heeft, past het in de webvise MVP development route.
De versie per week
Een MVP van 3 tot 5 weken is geen samengeperst volledig product. Het is een build waarbij de risicovolle beslissingen vóór de kickoff zijn genomen en de eerste release smal genoeg blijft om snel te testen.
| Fase | Wat gebeurt er | Beslissing nodig |
|---|---|---|
| Voor kickoff | Leerdoel, gebruiker, workflow, launchmetric, accounts en harde cuts zijn benoemd | Eén owner accepteert scopegrenzen |
| Week 1 | UX-flow, datamodel, auth, deployment en eerste klikbare pad | Geen nieuwe gebruikersrol zonder iets anders te verwijderen |
| Week 2 | Kernworkflow, databasewrites, email- of betaalpad, basisbehoefte voor admin | Integraties blijven standaard tenzij ze het product bewijzen |
| Week 3 | Echte data, analytics, foutafhandeling, mobiele checks, eerste interne test | Alleen defecten en launchblokkades komen in scope |
| Week 4 | Gebruikersgerichte polish, copy, overdracht, tracking, productiedeploy | Launch wint van nog een ronde voorkeurswijzigingen |
| Week 5 | Buffer voor feedback, betaalcases, partner-API-problemen of datacleanup | Alles zonder launchrelatie gaat na release |
De stack is niet de truc. webvise bouwt deze laag meestal met Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel en basisanalytics. De snelheid komt uit bekende onderdelen en de weigering om infrastructuur te verzinnen voordat het product bewijs heeft.
Wat van 3 weken 3 maanden maakt
De meeste MVP-vertragingen komen niet door moeilijke engineering. Ze komen door beslissingen die zacht bleven omdat niemand het nice-to-have werk wilde schrappen.
| Vertragingsbron | Hoe het klinkt | Hoe de planning blijft staan |
|---|---|---|
| Gebruikersrollen | 'Admin, koper, verkoper, partner en support hebben allemaal dashboards nodig' | Kies één primaire gebruiker en één interne operator |
| Integraties | 'We hebben CRM, billing, analytics, Slack en de oude database op dag één nodig' | Houd alleen het systeem dat de workflow bewijst |
| Goedkeuringslussen | 'Het team bekijkt het wanneer iedereen tijd heeft' | Noem één cut-owner met responstijd van 24 uur |
| Designscope | 'Laten we elke screen in Figma afmaken voordat we bouwen' | Ontwerp eerst het kernpad en polijst nadat het werkt |
| Complianceclaims | 'Misschien hebben we later audit logs nodig' | Bouw alleen de juridische en veiligheidschecks die eerste gebruikers nodig hebben |
Daarom telt een korte MVP-briefing meer dan een lange functielijst. De template in onze MVP requirements document guide is de versie die wij willen zien voordat een vaste-prijs build start.
Miniverhaal: OHYP had om de juiste redenen 6 weken nodig
Op 2026-02-20 publiceerden we de OHYP GmbH case study, een Berlijnse vastgoedservice die financieringscertificaten nodig had voor kopers in Duitsland. De businessbelofte was specifiek: een koper moest binnen 24 uur een bindend certificaat ontvangen, zonder SCHUFA-kredietcheck, terwijl het systeem meer dan 550 partnerbanken vergeleek.
Dat was geen MVP van 3 weken, en het zo noemen zou oneerlijk zijn geweest. De eerste release had een financieringsformulier van 10 stappen nodig, automatische PDF-certificaatgeneratie en een admin-dashboard voor de aanvraaglevenscyclus.
Het resultaat bleef toch lean: 6 weken, 96 Lighthouse performance, minder dan 1,2 s laadtijd en certificaatafhandeling binnen 24 uur. De planning ging voorbij 5 weken omdat de workflow echte financiële data en een echte operationele overdracht had, niet omdat het team decoratieve functies bleef toevoegen.
Miniverhaal: vibe-coded MVPs winnen dagen en verliezen daarna weken
Op 2026-05-18 schreven we over Lovable, Bolt en v0 MVPs. Die tools zijn nuttig voor prototypes omdat ze het idee van een founder binnen uren zichtbaar maken. Het probleem begint wanneer een prototype als productfundament wordt behandeld.
Het patroon is consistent genoeg dat we er een regel voor opschreven: wanneer een vibe-coded app echte gebruikers heeft, bouwen we opnieuw in plaats van te patchen. Een schone build op onze stack duurt meestal 3 tot 6 weken. Reddingswerk kan 8 tot 12 weken duren, omdat elke fix een schema, routestructuur en live datamodel moet respecteren dat niemand heeft ontworpen.
Dat is het minder opvallende antwoord, maar het is eerlijker voor het budget. Gebruik AI app builders om te leren wat het product moet doen. Gebruik een MVP-build wanneer het volgende dat u nodig heeft betrouwbare data van echte gebruikers is.
De planningstest van 30 minuten
Voordat u een bureau om een planning vraagt, haalt u de scope door deze test. Als u hem niet in 30 minuten kunt beantwoorden, is het project nog niet klaar voor een vaste kalender.
Eén zin: welke risicovolle aanname moet versie één bewijzen?
Eén gebruiker: wie gebruikt de eerste release vóór iedereen?
Eén workflow: welke stappen brengen die gebruiker van start naar waarde?
Eén metric: welk getal zegt binnen 30 dagen of u doorgaat?
Eén owner: wie kan scope binnen 24 uur schrappen of accepteren?
Bekende accounts: welke auth-, betaal-, email-, analytics-, hosting- en databaseaccounts zijn klaar?
Harde cuts: wat wordt niet voor launch geleverd, zelfs als iemand erom vraagt?
Als de antwoorden op één pagina passen, kan een MVP van 3 tot 5 weken realistisch zijn. Als de antwoorden een workshop nodig hebben, begin dan met de briefing. De kostenversie van dezelfde beslissing staat in onze MVP development cost guide.
Wanneer een langere MVP het eerlijke antwoord is
Sommige eerste releases moeten niet in 5 weken worden geperst. Gereguleerde data, medische claims, financiële beslissingen, marketplaces, mobiele app stores en complexe partner-APIs kunnen allemaal een langere build rechtvaardigen.
De test is simpel: beschermt de extra tijd een echte gebruiker, een echte transactie of een echte wettelijke plicht? Zo ja, houd die tijd. Als de extra tijd het product alleen vollediger laat voelen, schrap die.
webvise helpt founders die keuze te maken voordat code start. Als uw MVP smal genoeg moet zijn voor 3 tot 5 weken, is onze MVP development service de juiste route. Als het al een productieplatform is, zeggen we dat en scopen we anders.
Een goede MVP-planning is geen flex. Het is het gevolg van heldere scope, snelle beslissingen en een eerste versie die één businessvraag moet beantwoorden. Als u wilt dat webvise uw briefing vóór de build test, stuur hem naar ons.