Het MVP-idee is goed: bouw het kleinste ding dat je aanname bewijst. Maar in de praktijk eindigt een op de drie succesvolle MVP’s alsnog in een herbouw, precies op het moment dat het begint te lopen. Dat hoeft niet, mits je aan het begin een handvol keuzes bewust maakt.
Waarom MVP’s vastlopen op succes
Een MVP wordt gebouwd om snel iets te leren, en snelheid betekent bewust bochten afsnijden. Dat is prima, zolang je weet wélke bochten je afsnijdt. Het gaat mis als niemand dat heeft opgeschreven en de tijdelijke oplossing stilzwijgend de permanente wordt.
De pijn komt zelden van de hoeveelheid gebruikers. Hij komt van de tweede klant die net iets anders wil, de eerste koppeling met een extern systeem, en de eerste keer dat iemand vraagt wie wat wanneer heeft gewijzigd.
Vier keuzes die je later niet meer kunt maken
Dit zijn de beslissingen die diep in de architectuur zitten. Ze kosten aan het begin dagen en achteraf maanden:
- Het datamodel: is een klant een veld of een entiteit? Kan één gebruiker bij meerdere organisaties horen? Achteraf omzetten betekent migreren onder productiedruk.
- Multi-tenancy: ga je ooit meerdere klanten op dezelfde omgeving bedienen? Dat achteraf inbouwen raakt vrijwel elke query.
- Authenticatie en rechten: een rollenmodel dat verder gaat dan “gebruiker of beheerder” is later lastig inschuiven, omdat elk scherm ermee te maken heeft.
- Een API-grens: bouw de logica achter een duidelijke grens, ook als er nu alleen een webinterface is. Zonder die grens is de mobiele app of koppeling van volgend jaar een verbouwing.
Wat je juist wél uitstelt
Overengineering is net zo duur als onderengineering. Dit kun je met een gerust hart later doen: caching, geavanceerd zoeken, uitgebreide rapportages, automatisch schalen, een mooi ontworpen beheeromgeving en vrijwel elke integratie waar nog geen klant om heeft gevraagd.
De vuistregel: alles wat je kunt toevoegen zonder bestaande code te herschrijven, stel je uit. Alles wat later een herschrijving zou vragen, doe je nu.
Het moment van opschalen herkennen
Er zijn drie betrouwbare signalen: nieuwe functionaliteit kost structureel meer tijd dan een half jaar geleden, je team is meer bezig met herstellen dan met bouwen, en elke wijziging raakt onverwachte onderdelen.
Zie je die, plan dan een refactorsprint vóór de volgende grote functie in plaats van erna. Bij Eventura is het platform vanaf de start multi-tenant opgezet; daardoor kon het van eigen gebruik uitgroeien tot een dienst die ze aan collega-bureaus verkopen, zonder herbouw.
Zit je nu met een MVP die tegen zijn grenzen aanloopt? Een architectuurreview laat in een paar dagen zien wat je moet aanpakken en wat kan blijven.