Van idee naar MVP in 4 weken: een werkwijze die werkt

De term MVP wordt te vaak gebruikt voor iets wat eigenlijk een halfbakken prototype is. Een échte MVP — Minimum Viable Product — is iets waarmee mensen écht aan de slag kunnen, betalen voor de dienst, feedback leveren. Het levert één keten value end-to-end, niet twintig halve featuretjes.

Dit artikel beschrijft hoe ik dat consistent in vier weken lever, én waarom dat tempo de beste beslissing is die je als oprichter kunt nemen.

Waarom een strakke deadline je beste vriend is

Een project zonder deadline expandeert totdat het het gehele beschikbare budget opslokt. Een project met een deadline van vier weken dwingt tot keuzes die je anders niet had genomen — en 80% van die keuzes blijken achteraf goed.

Bovendien: binnen een maand krijg je in plaats van plannen dingen in handen van echte gebruikers. Hun feedback is tien keer waardevoller dan welke interne discussie ook.

Week 1 — Scope en keuzes

Geen regel code deze week. Wel: een harde lijst van wat wel en niet in de MVP zit.

Maandag — Intro en doel

Twee uur samen aan tafel. Wat is het probleem? Voor wie? Hoe weet je of je MVP werkt? Wat is het simpelste ding dat we kunnen maken dat die validatie biedt?

Dinsdag-woensdag — Scope-cutting

Je eerste lijst features is altijd te lang. Iedereen denkt: "maar we moeten ook X en Y hebben". Vrijwel altijd fout. Ik gebruik deze drie filters:

• Is deze feature nodig voor de eerste werkende flow? Nee → schrap.
• Kan ik dit handmatig doen in week 1 live-periode? Ja → handmatig doen, automatisering later.
• Zou ik vijf mensen willen bellen om deze feature te valideren? Nee → schrap.

Donderdag — Datamodel en flows

De vorm van de data bepaalt alles. Welke entiteiten (user, order, project)? Welke relaties? Welke kernflows (signup → create → share)?

Ik teken dit op papier, niet in tools. Tekening moet in 5 minuten uitlegbaar zijn. Als dat niet lukt, is je scope te breed.

Vrijdag — Voorstel en go/no-go

Eén pagina: scope, planning, prijs, acceptatiecriteria. Géén ambiguïteit. Jij weet waar je ja tegen zegt, ik weet waar ik ja tegen zeg.

Week 2 — Fundament bouwen

Nu code. De eerste week in bouw gaat over infrastructuur — dingen die niet zichtbaar zijn maar alles dragen.

Maandag — Project setup

Next.js project opzetten, Supabase aanzetten voor database + auth, Vercel deployment configureren, GitHub repo aan de gang. In 2026 duurt dit een middag ipv een week. Tools zijn volwassen.

Dinsdag-woensdag — Databaseschema + auth

Tabellen ontwerpen met de entiteiten uit week 1. Row-level security rules om gegevens per user te isoleren. Login, signup, wachtwoord-reset werkend krijgen.

Donderdag-vrijdag — UI-basis

Navigation, layout, een design-systeem dat consistent is. Tailwind + shadcn/ui versnellen dit enorm. Geen pixel-perfect finesse — functionele schoonheid.

Week 3 — Kernfunctionaliteit

De week waarin de MVP 'iets kan'. Focus: één volledige flow van begin tot eind, werkend.

Maandag-dinsdag — Primaire flow

Gebruiker logt in → doet hoofdactie → ziet resultaat. Dit is wat je MVP bestaansrecht geeft. Alles wat niet in deze flow zit, wacht.

Woensdag — Edge cases (de belangrijke)

Wat als de input leeg is? Wat als de server faalt? Wat als een user twee tabbladen tegelijk open heeft? Niet alles vooraf dichten, wel de drie voor de hand liggende scenario's.

Donderdag — Email/notificaties

Alleen transactional (welkom-mail, password-reset, order-bevestiging). Marketing-emails komen later, nu niet.

Vrijdag — Eerste deploy en interne test

Site live op een stealth-subdomein. Jij of team gebruikt het een heel dagelijks proces. Bugs komen boven. Oplossen voor maandag.

Week 4 — Testen, polish, lancering

De makkelijkste week in bouwtijd, maar de meest cruciale voor kwaliteit.

Maandag — Beta-testers

3–5 echte gebruikers krijgen toegang. Ik zit mee-kijkend in een scherm-deel sessie. Noteer elke keer dat ze aarzelen, foutklikken, of vragen stellen. Dat zijn je UX-bugs.

Dinsdag-woensdag — Bug fixes + polish

Lijst van beta-testers afhandelen. Belangrijkste bugs en frictie-punten. Niet alles — alleen de top 10 waar iedereen over viel.

Donderdag — Content en copywriting

De teksten die echte gebruikers gaan lezen. Homepage, onboarding, e-mails, error-messages. Dit maakt vaak meer impact dan een extra feature.

Vrijdag — Launch

Live, domein gekoppeld, analytics aan, eerste echte user kan zich aanmelden. Open een bier.

Wat je schrapt (en waarom dat goed is)

Vrijwel elke MVP die ik bouw mist initieel:

• Admin-panel — jij logt in op Supabase en doet het daar. Admin-panel bouw ik in week 8 als je 50+ users hebt.
• Fijn-granulaire rollen en permissies — start met "admin" en "user". Later verfijnen als het nodig blijkt.
• Analytics dashboards — een tabel in Supabase volstaat. Fancy charts komen later.
• Notificaties (in-app, push, etc.) — email is genoeg. Push is week 12.
• Branding fine-tuning — zorg dat 't nette fonts en kleuren heeft, meer niet. Logo-finalisatie post-launch.
• Responsive voor elk schermformaat — werkt mobile en desktop goed. Tablet landscape komt wel.
• Meertaligheid — start in één taal. Vertalen begint pas zodra je product-market-fit hebt.
• Geavanceerde zoek/filter — een simpele lijst of zoekveld volstaat tot je 100+ items hebt.

Dit schrappen voelt naar in week 1. In week 5 voel je je dankbaar.

Wanneer werkt 4 weken niet?

Voor projecten met compliance-eisen (medisch, financieel, overheid) moet je meer tijd inbouwen voor audit-trails, rapportages, security-reviews. Reken op 8–12 weken.

Voor hardware-gebonden of multi-platform projecten (iOS + Android + web) vermenigvuldig je grofweg met drie. Een MVP voor iOS alleen kan nog in 4–6 weken.

Voor échte AI-kernproducten (niet AI ingebouwd in een site, maar een AI-first product) kost het werkelijk valideren van de kern 2–3 weken langer — je hebt evaluation en prompt-tuning als aparte workstream nodig.

Na de vier weken

Een MVP is niet het einde van een project. Het is dag één van je écht leren wat bouwen is. Wat je vervolgens doet:

• Bekijk metrics — waar haken gebruikers af?
• Praat met de eerste 20 users — wat missen ze?
• Schip kleine wekelijkse verbeteringen — niet grote rewrites
• Bouw in maand 2 wat in week 1 is geschrapt, maar alleen de helft daarvan

De kunst is niet om in vier weken alles te bouwen. Het is om in vier weken de juiste dingen gebouwd te hebben zodat je de volgende vier weken richting krijgt van echte gebruikers.