Je hebt een idee voor een platform. Een nieuwe tool, een interne app, of een SaaS-product waarmee je een gat in de markt wilt invullen. De vraag die elke MKB-founder dan stelt: bouw ik direct het hele ding, of begin ik klein? In 9 van de 10 gevallen is het antwoord klein. Een MVP is de slimste manier om je idee te testen zonder eerst tonnen te investeren. Dit artikel legt uit hoe wij MVP-trajecten aanpakken voor MKB-bedrijven, welke fases je doorloopt, wat het kost, en welke fouten je beter overslaat.
Wat is een MVP eigenlijk?
Een MVP is de kleinst mogelijke versie van je product die echte gebruikers kunnen gebruiken en waarover ze nuttige feedback kunnen geven. De term komt uit Eric Ries zijn boek The Lean Startup en betekent minimum viable product.
Voor het MKB is een MVP een manier om risico te beperken. In plaats van zes maanden bouwen en dan ontdekken dat niemand het gebruikt, bouw je in drie weken een werkende versie en kijk je of mensen er iets mee doen. De winst zit niet in de tijd, maar in de informatie.
Wanneer kies je voor een MVP-aanpak?
- Vroege validatie. Je hebt een idee maar nog geen bewijs dat klanten ervoor willen betalen.
- Beperkt budget. Je hebt €10.000 tot €20.000 te besteden, niet €60.000.
- Onzekerheid over product-market-fit. Je weet niet precies welke feature het verschil maakt.
- Snelle test naast bestaande activiteiten. Je runt al een bedrijf en wilt iets nieuws testen zonder dat het je core afleidt.
- Beperkte tijd tot eerste oplevering. Je hebt een deadline van 2 tot 3 weken.
Twijfel je tussen MVP en full build? Lees onze gids over custom software laten bouwen.
Wat kost een MVP laten bouwen?
| Niveau | Investering | Doorlooptijd | Wat krijg je |
|---|---|---|---|
| Lite MVP | €8.000 tot €10.000 | 1 tot 2 weken | 1 kernfunctie, 1 user-rol, basis auth, ruwe UI. |
| Standaard MVP | €11.000 tot €14.000 | 2 weken | 2 tot 3 kernfuncties, 2 user-rollen, betaling of API-koppeling, nette UI. |
| Uitgebreid MVP | €15.000 tot €18.000 | 2 tot 3 weken | 3 tot 5 kernfuncties, meerdere rollen, complexere logica, integraties. |
Welke fases doorloop je in een MVP-traject?
| Fase | Duur | Wat gebeurt er | Wat krijg je |
|---|---|---|---|
| 1. Discovery | 2 werkdagen | Interviews met jou en 2-3 toekomstige gebruikers, scope-document | Scope-document, feature-lijst, vaste prijs. |
| 2. Design | 2 werkdagen | User-flows, wireframes, basis UI-design in Figma | Figma-bestanden, klikbaar prototype. |
| 3. Build | 6 tot 9 werkdagen | Database, backend, frontend, integraties, testen | Werkende staging, wekelijkse demo, productie-versie. |
| 4. Launch | 1 werkdag | Productie-hosting, monitoring, eerste gebruikers onboarden | Live MVP, monitoring, code-eigendom overdracht. |
Aan het eind van Launch ontvang je de volledige code als jouw eigendom. Wat code-eigendom precies betekent, lees je in code-eigendom en vendor lock-in uitgelegd.
Welke features horen WEL in een MVP?
- De ene kernactie waar het hele platform om draait. Eén actie, goed werkend.
- Basis-auth en gebruikersbeheer. E-mail en wachtwoord login, eventueel Google of Microsoft.
- De minimale data-structuur. Een database die je kernobjecten kan opslaan en ophalen.
- Een ruwe UI die werkt. Niet mooi, wel duidelijk.
- Een feedback-mechanisme. E-mailadres of in-app knop waarmee gebruikers reageren.
Voorbeelden van platforms die wij in MVP-vorm hebben opgeleverd staan op onze custom platforms pagina en in de cases Mastone en Simply.
Welke features horen NIET in een MVP?
- Uitgebreid admin-panel. In een MVP volstaat een eenvoudige database-view of spreadsheet-export.
- Multi-user samenwerking en rechten-rollen. Komt later.
- Volwaardig analytics dashboard. Gebruik PostHog, Plausible of Google Analytics.
- Eigen notificatie-engine. Begin met simpele e-mail via Postmark of Resend.
- White-label of theming. Komt na product-market-fit.
- Volledige integratie-suite. Begin met de ene koppeling die strikt noodzakelijk is.
- App in plaats van of naast web. Dubbele bouwkosten zonder dubbele leereffect.
Hoe meet je of je MVP slaagt?
- Adoptie: hoeveel mensen melden zich aan en gebruiken de kernactie?
- Retention: hoeveel mensen komen terug? Voor de meeste MVPs is 30 procent retention na 7 dagen al een goed teken.
- Feedback: wat zeggen gebruikers spontaan? Klagen ze over snelheid, design, ontbrekende functies?
Wat doe je na de MVP?
Na 8 tot 12 weken in productie heb je genoeg data om een beslissing te nemen. Steve Blank, een van de grondleggers van Customer Development, noemt dit het “pivot or persevere” moment.
- Pad 1: itereren. Je past de kernfunctie aan en draait nog een meet-cyclus.
- Pad 2: uitbreiden. Adoptie is sterk, je bouwt admin-panel, extra rollen, integraties.
- Pad 3: stoppen. De markt slaat niet aan. Je hebt €10.000 verloren in plaats van €80.000. Y Combinator noemt dit een van de waardevolste lessen.
In onze ervaring kiest 60 procent voor pad 2, 30 procent voor pad 1, en 10 procent voor pad 3. Beter een goed onderbouwde nee in week 12 dan een dure ja in maand 12.
Concreet voorbeeld: MVP voor een fictief MKB
Een Nederlandse interieur-installateur wil een platform waar onderaannemers hun beschikbaarheid en planning delen. Wij stellen voor: een Standaard MVP van €12.000, 2 weken doorlooptijd. Na 6 weken: 8 bedrijven aangemeld, 6 voeren wekelijks planning toe, retention op 65 procent. Beslissing: pad 2, uitbreiden. Begroting fase 2: €18.000. Totaal na 6 maanden: €30.000 voor een gevalideerd platform, in plaats van €80.000 voor een Full Build.
Welke deliverables krijg je per fase?
Veel MVP-trajecten lopen vast omdat onduidelijk is wat je per fase concreet in handen krijgt. Wij koppelen elke fase aan een vaste set documenten en assets. Op die manier weet je in week 1 wat je in week 3 hebt liggen, en kun je elke fase apart goedkeuren voordat de volgende start.
| Fase | Deliverables | Waar staat het |
|---|---|---|
| Discovery | scope.md, feature-lijst met prioriteit, vaste prijs-offerte, risico-lijst | Gedeelde Notion of Google Drive, jouw eigendom. |
| Design | Figma met wireframes, klikbaar prototype, flow.md met user-flows en edge cases | Figma-bestand op jouw account, flow-doc in repo. |
| Build | GitHub-repo, staging-omgeving, wekelijkse demo-video van 5 minuten, release notes | GitHub onder jouw organisatie, video in Drive. |
| Launch | productie-omgeving, handover.md, monitoring-dashboard, video-walkthrough beheer | Repo, hosting-account en docs in jouw beheer. |
Hoe prioriteer je features voor een MVP?
Ondernemers willen vrijwel altijd meer features dan in een MVP passen. Wij gebruiken twee simpele frameworks naast elkaar tijdens discovery: MoSCoW voor de grove sortering, en ICE voor de fijne afweging binnen “Must” en “Should”.
- MoSCoW. Elk feature-idee krijgt het label Must, Should, Could of Won’t. In een Lite MVP horen alleen Must-items. In een Standaard MVP voeg je een paar Should-items toe.
- ICE-score (Impact, Confidence, Ease). Per feature scoor je drie getallen van 1 tot 10, vermenigvuldig die, en sorteer aflopend. Bovenste 3 tot 5 features gaan mee.
- Drie-vragen-test per feature. Lost dit een echt klantprobleem op, kunnen we het in 5 dagen bouwen, en kunnen we het meten na launch? Drie keer ja: in scope. Twijfel: op de fase-2 lijst.
- Trade-off zichtbaar maken. Elke “ja” aan een nieuwe feature is een “nee” tegen iets anders. Wij laten in de scope-tabel altijd zien welk feature plaats maakt voor een nieuwe wens.
Voor een dieper kijkje in scope-keuzes zie de Mastone case study, waar we de eerste versie van 11 naar 4 kernfuncties hebben teruggebracht.
Welke scope-fouten zien wij het vaakst?
In 4 jaar MVP-trajecten bij MKB-bedrijven komen dezelfde valkuilen terug. De meeste zijn te voorkomen door in discovery harder door te vragen. Hieronder de vijf patronen die we het vaakst tegenkomen, met de simpele tegenmaatregel.
- Fout 1: bouwen voor “iedereen”. De founder noemt drie verschillende doelgroepen in één zin. Tegenmaatregel: kies één gebruiker, één probleem, één kernactie voor de MVP.
- Fout 2: admin-paneel meebouwen. “We hebben toch een beheerscherm nodig.” Tegenmaatregel: in de MVP volstaat direct database-toegang via een tool als Retool of een eenvoudige export.
- Fout 3: integratie-roadmap van 6 koppelingen. Tegenmaatregel: kies de ene koppeling zonder welke het product niet werkt. De rest gaat naar fase 2.
- Fout 4: design-perfectionisme. Drie design-rondes voordat er code staat. Tegenmaatregel: design tot 80 procent en testen met echte gebruikers, niet met collega’s.
- Fout 5: rollen en rechten van dag 1. “Onze klanten hebben 4 verschillende rollen nodig.” Tegenmaatregel: start met 1 of 2 rollen en voeg pas toe als gebruikers er expliciet om vragen.
Hoe blijf je leren na de launch?
Een MVP eindigt niet bij de launch. De waarde zit in wat je leert in de eerste 12 weken in productie. Wij werken met 2-weekse iteratie-cycli waarin we meten, beslissen en bijsturen. Zonder die ritmes wordt elke MVP stil binnen 3 maanden.
- Week 1 tot 2 na launch: stabilisatie. Bugs oplossen, performance fine-tunen, eerste gebruikers begeleiden via WhatsApp of e-mail.
- Week 3 tot 6: meet-cyclus 1. Adoptie en retention meten via PostHog of Plausible, 5 gebruikers interviewen over hun ervaring.
- Week 7 tot 10: meet-cyclus 2. Eerste kleine verbeteringen live (kopij, formulieren, e-mailflows), tweede meetronde.
- Week 11 tot 12: beslis-moment. Pivot, persevere of stop. Onderbouwd met data en interviews, niet met onderbuikgevoel.
In onze pakketten zit een doorlopend pakket vanaf €750 per maand voor kleine iteraties na de MVP. Geen jaarcontract, maandelijks opzegbaar.
Hoe begin je concreet?
- Stap 1: omschrijf in 5 zinnen wat je MVP moet kunnen. Wie is de gebruiker, wat is de ene kernactie, hoe verdien je geld, wat is je deadline.
- Stap 2: plan een gratis intake. In 30 minuten kijken we naar je beschrijving en geven een eerlijke inschatting.
- Stap 3: discovery starten. Aan het eind ligt er een vast contract met scope, prijs en planning.
Plan een gratis intake-gesprek. Onze werkwijze en correctie-garantie staan in onze algemene voorwaarden. Voor inspiratie: cases Mastone, Simply en Planit Consulting.
