Hoe lang duurt het om een MVP te bouwen? Een gerichte web-MVP kost 3 tot 5 weken wanneer die één workflow test met standaard-auth, één datamodel en één succescriterium. Het wordt 6 tot 12 weken of meer wanneer de opdracht meerdere rollen, zware integraties of commissiegoedkeuring omvat.
Het ongemakkelijke deel is dat de planning doorgaans een scopebeslissing is, geen technische wetmatigheid.
Als u op dit moment offertes vergelijkt, is de spreiding waarschijnlijk verwarrend om een begrijpelijke reden. Sommige teams brengen een eerste test in rekening, anderen een kleine versie van het eindproduct. Deze gids geeft u de tijdlijn die bij webvise wordt gehanteerd, de blokkades die die tijdlijn oprekken, en de snijregels die voorkomen dat een MVP doet alsof het een volledige build is.
- 3 tot 5 weken is realistisch voor één kernworkflow. Dat betekent één primaire gebruiker, één taak, één databasestructuur, één lanceercriterium en snelle beslissingen.
- 6 tot 12 weken is normaal wanneer de scope meerdere rollen of diepe integraties omvat. Dat betekent een grotere eerste release.
- De eerste week bepaalt de tijdlijn. Trage accounttoegang, vage acceptatiecriteria en late API-beslissingen kosten meer tijd dan code.
- webvise scopt MVP-builds rond één centraal leerdoel en kan gerichte eerste releases in 3 tot 5 weken opleveren op Next.js, PostgreSQL en Vercel, met auth, betalingen en een investeerdersklare demo-omgeving waar die toe doen. Bekijk de servicespecificatie.
- De veiligste MVP is het kleinste product dat binnen 30 dagen na lancering een beslissing kan opleveren.
Het Korte Antwoord per Scope
Publieke MVP-tijdlijnsgidsen landen doorgaans tussen de 4 en 12 weken. Dat bereik verbergt de nuttige vraag: om wat voor soort MVP gaat het?
Bij webvise hangt het antwoord af van de scopevorm. De belofte van 3 tot 5 weken geldt voor een web-MVP met een heldere workflow, een vaste tech-stack en een beslissingshouder die features kan schrappen tijdens de build.
| Scopevorm | Gebruikelijke tijdlijn | Wat het bewijst |
|---|---|---|
| Klikbaar prototype | 2 tot 5 dagen | Begrijpt iemand het aanbod en de flow? |
| No-code test | 1 tot 2 weken | Klikken, registreren of betalen mensen al voordat de software bestaat? |
| Gerichte web-MVP | 3 tot 5 weken | Kan één gebruiker de kernworkflow voltooien met echte data? |
| Standaard product-MVP | 6 tot 12 weken | Kunnen meerdere rollen het product gebruiken met echte integraties? |
| Gereguleerde of marketplace-MVP | 12+ weken | Kan het product risico, rechten, compliance of tweezijdige vraag aan? |
Als uw idee eerst een landingspagina, wachtlijst en handmatige follow-up nodig heeft, betaal dan nog niet voor een MVP. Heeft het auth, één workflow, een database, deployment en analytics nodig, dan past het in de webvise MVP development-lijn.
De Week-voor-Week Versie
Een MVP van 3 tot 5 weken werkt wanneer de riskante beslissingen voor de kickoff zijn genomen en de eerste release smal genoeg is om snel te testen.
| Fase | Wat er gebeurt | Benodigde beslissing |
|---|---|---|
| Voor kickoff | Leerdoel, gebruiker, workflow, lanceercriterium, accounts en harde snijpunten worden benoemd | Één eigenaar accepteert de scopegrenzen |
| Week 1 | UX-flow, datamodel, auth, deployment en eerste klikbaar pad | Geen nieuwe gebruikersrol zonder iets te verwijderen |
| Week 2 | Kernworkflow, database-writes, e-mail- of betalingspad, basisbeheerdersbehoefte | Integraties blijven standaard tenzij ze het product bewijzen |
| Week 3 | Echte data, analytics, foutafhandeling, mobiele controles, eerste interne test | Alleen defecten en lanceerblokkers komen in scope |
| Week 4 | Gebruikersgerichte afwerking, teksten, overdracht, tracking, productie-deploy | Lancering gaat voor een nieuwe ronde voorkeursbewerkingen |
| Week 5 | Buffer voor feedback, betalingsrandgevallen, partner-API-problemen of dataopschoning | Alles wat niet aan de lancering gebonden is, verschuift naar na de release |
De stack is niet de truc. Bij webvise wordt dit niveau doorgaans gebouwd met Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel en basisanalytics. De snelheid komt voort uit het gebruik van bekende onderdelen en het weigeren om infrastructuur te verzinnen voordat het product bewijs heeft.
Wat 3 Weken in 3 Maanden Verandert
De meeste MVP-vertragingen komen niet voort uit technisch zware klussen. Ze komen van beslissingen die vaag zijn gebleven omdat het team vermeed nice-to-have werk te schrappen.
| Vertragingsoorzaak | Hoe het klinkt | Hoe de tijdlijn te bewaken |
|---|---|---|
| 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" | Bewaar alleen het systeem dat nodig is om de workflow te bewijzen |
| Goedkeuringsrondes | "Het team beoordeelt wanneer iedereen tijd heeft" | Benoem één beslissingshouder met 24-uurs reactietijd |
| Designscope | "Laten we eerst elk scherm in Figma afmaken voor de build" | Ontwerp eerst het kernpad en polijst het nadat het werkt |
| Compliance-aannames | "Misschien hebben we later auditlogs nodig" | Bouw alleen de wettelijke en veiligheidscontroles die nodig zijn voor eerste gebruikers |
Daarom is een korte MVP-briefing belangrijker dan een lange featurelijst. De template in de MVP-requirements-documentgids is de versie die nodig is voordat een scoped build begint.
Mini-Story: De Scope Was Terecht Smal
In een vastgoed-MVP was de deadline niet willekeurig. De zakelijke belofte was concreet: een koper moest een bindend financieringsattest ontvangen zonder een kredietbureaucheck, terwijl het systeem op de achtergrond partnerbanksopties vergeleek. Dat soort product kan snel bewegen wanneer de eerste versie één workflow beschermt in plaats van een volledig financieel platform te willen worden.
Dat was geen kleine MVP, en dat zo noemen zou oneerlijk zijn geweest. De eerste release vereiste een complete financieringsworkflow, geautomatiseerde PDF-certificaatgeneratie en een beheerdersdashboard voor de aanvraaglevenscyclus.
Het resultaat bleef toch lean: een gerichte build, sterke Lighthouse-prestaties, snelle paginaopbouw en certificaatafhandeling binnen het beloofde servicevenster. De tijdlijn rekte uit omdat de workflow echte financiële data en een echte operationele overdracht had, niet omdat het team decoratieve features bleef toevoegen.
Mini-Story: Vibe-Coded MVPs Besparen Dagen, Verliezen dan Weken
Op 2026-05-18 verscheen een artikel over Lovable, Bolt en v0 MVPs. Die tools zijn nuttig voor prototypes omdat ze het idee van een founder in uren zichtbaar maken. Het probleem begint wanneer een prototype als de productbasis wordt behandeld.
Het patroon is consistent genoeg dat er een regel voor op papier staat: wanneer een vibe-coded app echte gebruikers heeft, wordt die herbouwd in plaats van gepatcht. Een schone build op de eigen stack kost doorgaans 3 tot 6 weken. Salvagewerk kan 8 tot 12 weken duren omdat elke fix een schema, routestructuur en live-datamodel moet respecteren dat nooit bewust is ontworpen.
Dat is het minder glanzende antwoord, maar het is vriendelijker voor het budget. Gebruik AI-appbouwers om te leren wat het product moet doen. Gebruik een MVP-build wanneer wat u daarna nodig heeft betrouwbare data van echte gebruikers is.
De 30-Minuten Tijdlijntest
Voordat u een bureau om een tijdlijn vraagt, zet u de scope door deze test. Als u hem niet binnen 30 minuten kunt beantwoorden, is het project nog niet klaar voor een vaste planning.
- Één zin: welke riskante aanname moet versie één bewijzen?
- Één gebruiker: wie gebruikt de eerste release als eerste?
- Één workflow: welke stappen brengen die gebruiker van invoer naar waarde?
- Één maatstaf: welk getal vertelt u binnen 30 dagen of u door moet gaan?
- Één eigenaar: wie kan scope binnen 24 uur snijden of accepteren?
- Bekende accounts: welke auth-, betalings-, e-mail-, analytics-, hosting- en database-accounts zijn klaar?
- Harde snijpunten: wat verschijnt niet voor de lancering, ook al vraagt iemand erom?
Als de antwoorden op één pagina passen, is een MVP van 3 tot 5 weken mogelijk realistisch. Als de antwoorden een workshop vereisen, begin dan met de briefing. De kostenversie van dezelfde beslissing staat in de MVP-ontwikkelkostengids.
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 appstores en complexe partner-API's kunnen allemaal een langere build rechtvaardigen.
De test is eenvoudig: beschermt de extra tijd een echte gebruiker, een echte transactie of een echte wettelijke verplichting? Zo ja, bewaar het. Geeft de extra tijd het product alleen een completer gevoel, schrap het dan.
webvise helpt founders die afweging te maken voordat de code begint. Als uw MVP smal genoeg is voor 3 tot 5 weken, is de MVP-developmentservice de juiste route. Als het al een productieplatform is, hoort u dat eerlijk, en wordt het anders gescoopt.
Een goede MVP-tijdlijn komt voort uit heldere scope, snelle beslissingen en een eerste versie die bestaat om één zakelijke vraag te beantwoorden. Wilt u dat webvise uw briefing onder druk test voordat u bouwt, stuur hem dan op.