Hoe lang duurt het om een MVP te bouwen?

Met een MVP test je een concrete aanname: gebruiken mensen je product, betalen ze ervoor of komen ze terug?

Functies die nodig zijn om die vraag te testen horen in de eerste versie. De overige ideeën kunnen wachten. Dat helpt om de planning beheersbaar te houden.

Drie keuzes, in volgorde van impact.

• Accounts kosten tijd: registreren, inloggen, wachtwoordherstel en toegangsrechten. Voor een eerste test van interesse kan een wachtlijst genoeg zijn.
• Wil je testen of mensen betalen, dan heb je een werkende checkout en betaalafhandeling nodig. Voor andere vragen kun je betalingen mogelijk later toevoegen.
• Ontwerpbeslissingen beïnvloeden de planning. Als schermen en gebruikersroutes nog niet duidelijk zijn, reserveren we daar tijd voor vóór of tijdens de bouw.

Niet in het programmeren. In de rondes.

Feedback heeft een plek in de planning nodig. Late reacties kunnen de bouw vertragen, vooral als eerdere keuzes opnieuw besproken moeten worden.

We spreken vaste reviewmomenten af met iemand die beslissingen kan nemen. Dat geeft ruimte voor feedback zonder het werk lang stil te zetten.

Eerst bepalen we de vraag en bakenen we de eerste release af. Ook prijs, beschikbare ontwikkeltijd en opleverdatum worden afgesproken.

Daarna bouw ik de belangrijkste gebruikersroute. Je kunt de werkende versie proberen en vroege feedback verzamelen.

Tijdens de bouw beoordelen we regelmatig de voortgang en toetsen we wijzigingen aan de afgesproken scope.

We lanceren met analytics en foutregistratie en leggen vast wat voor een volgende versie is bewaard.

Als je al weet dat klanten het product nodig hebben, gaat de eerste release mogelijk over bruikbaarheid en levering in plaats van het testen van vraag.

We bespreken welk doel je eerste versie heeft. Ik werk naast mijn fulltime baan en reserveer maximaal 20 uur per week voor freelance werk; de planning moet daarin passen.