Een stack kiezen voor een MVP waar je echt mee verder kunt

De meeste oprichters stellen de vraag naar de juiste stack verkeerd om. Ze vragen wat het snelst, het nieuwst of het best schaalbaar is, terwijl de vraag die er echt toe doet luidt: wat willen we over drie jaar nog steeds graag onderhouden, met het team dat we realistisch gezien kunnen aannemen? Een MVP is geen wegwerpprototype. Als het werkt, wordt het gewoon je product — en elke shortcut in week één wordt een belasting die je daarna elke week betaalt.

Dit is het kader dat we met klanten doorlopen voordat er ook maar één regel code wordt geschreven.

1. Begin bij het probleem, niet bij de tools

Een boekingsplatform, een marktplaats en een intern dashboard zien er van binnen heel verschillend uit. Schrijf de drie of vier dingen op die het product op dag één moet kunnen, en welke data elk daarvan raakt. Die lijst zegt je meer over de juiste stack dan welke vergelijkingstabel ook.

• Draait het vooral om content en formulieren? Dan is een modern webframework met een beheerde database ruim voldoende.
• Gaat er geld doorheen? Kies tools met volwassen betaalbibliotheken en een duidelijke audittrail.
• Is het realtime — chat, live tracking, samen in één document werken? Plan dat dan vanaf het begin in; het er later bij bouwen is pijnlijk.
• Gebruiken de meeste mensen het op hun telefoon? Bepaal vroeg of je een native app nodig hebt, of dat een snelle, installeerbare webapp volstaat.

2. Kies bewust voor saaie technologie

Saai betekent niet oud. Het betekent goed begrepen: veel gebruikt, goed gedocumenteerd, en voor de meeste problemen staat het antwoord al ergens online. Voor de meeste webproducten komt dat vandaag neer op TypeScript, React met een framework zoals Next.js, en een gangbare database zoals PostgreSQL of MongoDB bij een beheerde host.

Het voordeel zit niet in technische elegantie. Het zit erin dat als er om twee uur ’s nachts iets stukgaat, de oplossing één zoekopdracht verderop ligt, en dat je een tweede developer in weken kunt aannemen in plaats van maanden. Elke ongebruikelijke keuze in je stack verkleint de groep mensen die eraan kan werken.

Besteed je innovatiebudget aan het product, niet aan het loodgieterswerk. Klanten zien je database nooit — ze zien alleen of het werkt.

3. Maak werving onderdeel van de beslissing

Ben je een niet-technische oprichter, dan is de stack ook een personeelsbeslissing. Stel bij elke voorgestelde technologie drie vragen: hoeveel developers in jouw markt kennen het, wat kosten ze, en kan een nieuwe developer de codebase in de eerste week begrijpen? Een stack waar je bureau dol op is maar waar verder niemand mee kan werken, maakt je ongemerkt afhankelijk.

Daarom documenteren we elk project en houden we het bij gangbare tools. Wil je de ontwikkeling ooit in eigen huis halen of naar een ander team overstappen, dan moet dat kunnen — en dat besef houdt iedereen eerlijk.

4. Koop in wat niet je kernactiviteit is

Authenticatie, betalingen, e-mailverzending, bestandsopslag, zoekfunctie en analytics zijn opgeloste problemen. Beheerde diensten doen dat beter dan een week maatwerkcode ooit kan, en op MVP-schaal kosten ze heel weinig. Dit soort dingen zelf bouwen is de meest voorkomende reden dat eerste versies uitlopen.

• Betalingen: een gangbare betaalprovider die in jouw markt beschikbaar is, in plaats van een maatwerkkoppeling met een bank.
• E-mail: een provider voor transactionele e-mail, zodat wachtwoordresets en betaalbevestigingen ook echt aankomen.
• Content: een headless CMS, zodat je team pagina’s kan aanpassen zonder developer.
• Hosting: een beheerd platform dat bij elke push automatisch deployt, in plaats van een server waar iemand op moet passen.

De vuistregel: bouw zelf wat je product onderscheidend maakt, en huur al het andere. Je kunt een dienst later altijd vervangen, als je precies weet wat je ervan nodig hebt.

5. Ontwerp voor de komende drie jaar, niet voor de komende tien

Oprichters maken zich vaak zorgen over schaal die ze nog niet hebben. Een goed gebouwde applicatie op een gangbare stack kan je eerste tienduizenden gebruikers prima aan; tegen de tijd dat dat niet meer lukt, heb je omzet, data over hoe het product echt wordt gebruikt en een veel beter idee van wat je moet optimaliseren. Microservices, Kubernetes en databases in meerdere regio’s lossen problemen op die je later graag zult hebben.

Waar je wél vroeg in moet investeren, is de saaie discipline die veranderingen goedkoop maakt: een heldere mappenstructuur, getypeerde code, automatische deploys, foutmonitoring en een handvol tests rond de onderdelen die met geld of persoonsgegevens werken.

Een korte checklist voordat je je vastlegt

1. Kun je in één zin uitleggen waarom elke belangrijke tool is gekozen?
2. Kun je in jouw markt binnen een maand een developer voor deze stack vinden?
3. Worden authenticatie, betalingen en e-mail afgehandeld door beproefde diensten?
4. Wordt elke push automatisch gedeployd, met een manier om terug te draaien?
5. Is er foutmonitoring, zodat jij bugs ziet voordat je klanten ze melden?
6. Is de code van jou — in jouw repository, onder jouw account?

Is het antwoord op alle zes ja, dan is je stack goed genoeg — en goed genoeg dat dit kwartaal live gaat, wint van perfect volgend jaar. Wil je een second opinion over een stack of een voorstel dat je hebt gekregen? Stuur het ons; we geven je graag een eerlijk oordeel.