MVP of volledige app: wat bouw je eerst?

"De eerste versie is klaar als er niets meer af kan, niet als er niets meer bij kan."

Het woord MVP klinkt als iets uit de startupwereld, maar de gedachte is eenvoudig. Je bouwt eerst het kleinste geheel dat echt iets oplost, laat echte mensen ermee werken en leert wat erbij moet. Het is de manier om te voorkomen dat je maanden bouwt aan iets wat niemand blijkt te gebruiken.

Kort antwoord: een MVP is een complete versie van het minimale, niet een halve versie van alles. Je bepaalt hem door één gebruikerspad te kiezen dat het meest oplevert, alles wat daar niet voor nodig is op een lijst voor later te zetten en dat schriftelijk vast te leggen. Inloggen, rechten en beveiliging horen er wel in.

Inhoudsopgave

1. Wat een MVP wel en niet is
2. Stap 1: wie, en wat wil die persoon bereiken
3. Stap 2: kies één pad
4. Stap 3: de weglaatlijst
5. Stap 4: leg het vast
6. Wat er wél altijd in hoort
7. Hoe je uitdijing tegenhoudt
8. Voorbeeld: een ledenportaal

---

Wat een MVP wel en niet is

Het is	Het is niet
Een werkend product voor echte gebruikers	Een tekening of klikbaar plaatje
Een klein geheel dat compleet is	Een groot geheel dat half af is
De basis waar je op doorbouwt	Een wegwerpprototype
Een manier om te leren	Een excuus om slecht te bouwen

Het verschil tussen een prototype en een MVP zit in de gebruiker. Een prototype laat zien wat kan. Een MVP wordt gebruikt.

Stap 1: wie, en wat wil die persoon bereiken

Begin niet bij functies maar bij mensen. Schrijf voor elke soort gebruiker één zin:

Als [rol] wil ik [doel], zodat [reden].

Bijvoorbeeld: "Als lid wil ik mij inschrijven voor een activiteit, zodat ik niet hoef te bellen." Of: "Als coördinator wil ik zien wie zich heeft aangemeld, zodat ik de groepen kan indelen."

Meer dan drie rollen in een eerste versie is zelden verstandig. Elke rol is eigenlijk een eigen omgeving: andere schermen, andere rechten, ander testwerk.

Stap 2: kies één pad

Een pad is de route die een gebruiker volgt van begin tot eind om iets te bereiken. Inloggen, een overzicht zien, een keuze maken, bevestigd krijgen.

Vraag jezelf: welk pad levert het meeste op als het werkt? Dat bouw je eerst, helemaal, van begin tot eind. Niet alle paden half.

Een hulpmiddel is een tabel met vier vragen per mogelijk pad:

Pad	Hoe vaak komt het voor?	Hoeveel tijd kost het nu?	Kan het ook zonder software?
Inschrijven voor activiteit	Elke week	3 uur telefoon	Nee
Nieuwsbrief versturen	Maandelijks	30 minuten	Ja, bestaand programma
Ledenoverzicht exporteren	Eens per kwartaal	1 uur	Ja, Excel

Het eerste pad scoort hoog op frequentie en tijd en niet op alternatieven. Dat is je kandidaat.

Stap 3: de weglaatlijst

Dit is het moeilijkste deel, omdat alles wat je weglaat een wens van iemand is. Maak er een lijst van, zodat het geen verlies voelt maar een uitstel.

Veelvoorkomende dingen die kunnen wachten:

• een uitgebreid dashboard met grafieken;
• meldingen per e-mail en per app;
• een eigen huisstijl tot in detail (een nette standaard volstaat in het begin);
• koppelingen met systemen die ook handmatig kunnen;
• een zoekfunctie, filters en exportopties;
• meerdere talen;
• uitgebreid beheer van instellingen.

Wat er niet bij hoort op die lijst, is wat de gebruiker nodig heeft om het pad te kunnen doorlopen. Dat bepaalt de grens.

Een vuistregel: twijfel je over een functie, vraag dan: kan de gebruiker zijn doel zonder deze functie bereiken? Zo ja, dan gaat hij naar de lijst.

Stap 4: leg het vast

Schrijf op wat er in de eerste versie zit, in gewone taal, en laat de opdrachtgever het goedkeuren. Een pagina is genoeg. Zet erbij wat er niet in zit.

Waarom dat zo belangrijk is: zonder schriftelijke afbakening kruipen wensen er stilletjes in. Na drie weken ben je een maand verder. Met een vast document kun je zeggen: "Dat is een goede wens, die staat voor fase 2." Een vaste prijs werkt alleen met een vaste inhoud. Zie maatwerksoftware laten bouwen: de complete gids en wat kost een app laten bouwen.

Wat er wél altijd in hoort

Klein betekent niet slordig. Deze dingen wil je in de eerste versie, ook al lijken ze niet af te leiden van het doel:

• Veilig inloggen en een wachtwoordherstel.
• Rechten: wie ziet wat, en wie mag wat wijzigen.
• Basisbeveiliging van gegevens, en afspraken over de AVG als je persoonsgegevens opslaat.
• Een back-up en een manier om gegevens te exporteren.
• Foutmeldingen die een gebruiker begrijpt.
• Werken op een telefoon, als je gebruikers daar zitten.

Als je dit later toevoegt, bouw je vaak opnieuw. Dat is duurder dan het meteen goed doen. Wat je met AI wel en niet sneller kunt, staat in bouwen met AI.

Hoe je uitdijing tegenhoudt

Uitdijing is het stilletjes groter worden van een project. Dit helpt:

• Eén beslisser aan jouw kant die ja of nee zegt.
• Een wekelijkse blik op iets werkends, geen presentatie.
• Elke nieuwe wens krijgt een plek: in versie 1.0 als iets anders eruit gaat, anders op de lijst.
• Echte gebruikers testen vroeg. Hun reactie is zwaarder dan wat de projectgroep denkt.

Zo ziet een traject van twee tot drie weken eruit in zo bouw ik een werkende app in drie weken.

Voorbeeld: een ledenportaal

Dit is een illustratie, geen klantcasus. Een vereniging wil een ledenportaal.

De wensenlijst: inloggen, profiel, activiteiten, inschrijven, betalen, nieuwsbrief, forum, ledenpas, fotoalbum, ledenlijst, statistieken.

De eerste versie: inloggen, activiteiten bekijken, inschrijven en een overzicht voor de coördinator.

Fase 2 (de lijst): betalen, nieuwsbrief, profiel, ledenpas.

Niet nu (misschien nooit): forum, fotoalbum, statistieken.

De eerste versie lost het probleem op dat de coördinator drie uur per week aan de telefoon zit. De rest hangt af van wat de leden en de coördinator na enkele weken daadwerkelijk missen.

---

Hulp nodig?

Heb je een idee en wil je weten wat daarvan in een eerste versie past? In een gesprek van dertig minuten maken we samen de lijst. Plan het via contact of bekijk de Rapid Solution Studio.

---

Gerelateerde artikelen

• Maatwerksoftware laten bouwen: de complete gids
• Bouwen, kopen of no-code: een beslismodel
• Bouwen met AI: hoe een app in weken kan en waar de grenzen zitten
• Zo bouw ik een werkende app in drie weken
• Bedrijfssysteem laten bouwen: wat eerst en wat later

Bronnen en verder lezen

• MKB Digitaal, praktische informatie over digitalisering
• Business.gov.nl, informatie voor ondernemers

---

Dit artikel is geschreven door Vincent van Munster van WeAreImpact. Hij bouwt eerste versies van web-apps in twee tot drie weken, met een vaste inhoud en een vaste prijs.