De architectuurkeuzes die je nu maakt merk je vaak pas over twee jaar, als je product groeit en de verkeerde keuze opeens een dure keuze blijkt. In van idee naar succesvolle software noemde ik dat je eenvoudig kunt beginnen met een monoliet of direct modulair kunt opzetten. Omdat deze keuze grote gevolgen heeft voor hoe je product later schaalt, ga ik hier dieper op in.
Een monoliet, eenvoudig starten met alles op een plek
Een monoliet is een architectuur waarbij alle onderdelen van je software in een samenhangend geheel gebouwd zijn. Dat maakt een monoliet in de beginfase overzichtelijk en snel te ontwikkelen, want alles staat op een plek en er is weinig overhead in hoe onderdelen met elkaar communiceren. Voor de meeste start-ups is een monoliet in de eerste fase de verstandigste keuze, simpelweg omdat je nog niet weet welke onderdelen van je product op termijn het meeste verkeer gaan krijgen.
Modulair opzetten, meer flexibiliteit tegen een hogere startcomplexiteit
Bij een modulaire architectuur knip je je software op in losse onderdelen die apart kunnen worden ontwikkeld, getest en opgeschaald. Dat geeft meer flexibiliteit zodra je product groeit, want je kunt het onderdeel dat het meeste verkeer krijgt apart opschalen zonder de rest van het systeem aan te raken. De prijs die je daarvoor betaalt, is een hogere complexiteit vanaf dag een, wat in de vroege fase van een start-up vaak meer kost dan het oplevert.
Wanneer schaalbaarheid echt een probleem wordt
Schaalbaarheid wordt pas een concreet probleem als je product daadwerkelijk op de grenzen van zijn architectuur botst, bijvoorbeeld doordat een onderdeel het hele systeem vertraagt bij drukte, of doordat een klein team niet meer veilig wijzigingen kan doorvoeren zonder andere onderdelen te breken. Founders die deze omslag te vroeg maken, betalen jarenlang voor complexiteit die ze niet nodig hadden. Founders die de omslag te laat maken, lopen tegen groeipijn aan op het moment dat het product juist succesvol wordt.
Hoe je vandaag kiest zonder jezelf morgen vast te zetten
De oplossing die ik founders meestal adviseer, is starten met een goed gestructureerde monoliet, gebouwd op een bewezen, open source framework zoals Laravel, zodat losse onderdelen later relatief eenvoudig uit elkaar te trekken zijn als dat nodig blijkt. Zo houd je de eenvoud van een monoliet in de beginfase, zonder jezelf technisch vast te zetten voor de toekomst. Hoe deze keuze samenhangt met je platformkeuze, webapp, PWA of native app, beschrijf ik in welk platform bij jouw gebruikers past.
Wanneer overstappen niet meer nodig is
Niet elk product groeit uiteindelijk naar een punt waarop een modulaire architectuur nodig is, en dat is geen probleem. Sommige producten blijven hun hele levensduur prima functioneren als monoliet. Laat de daadwerkelijke groei en complexiteit van je product de doorslag geven, niet de wens om technisch vooruitstrevend te ogen.
Hoe je een geleidelijke overgang aanpakt
Een overstap van monoliet naar modulair hoeft niet in één keer. De meeste teams knippen geleidelijk onderdelen los, te beginnen bij het onderdeel dat de meeste groei of onderhoud vraagt. Deze aanpak beperkt het risico aanzienlijk vergeleken met een volledige herbouw ineens, en geeft je team de tijd om aan de nieuwe structuur te wennen.
Wat je hierover moet vastleggen
Leg architectuurkeuzes en de redenen erachter altijd kort schriftelijk vast, ook als het nu vanzelfsprekend voelt. Een nieuw teamlid dat over een jaar instroomt, heeft niets aan een keuze die alleen in iemands hoofd zit en nooit is opgeschreven.
Wat teamgrootte met deze keuze te maken heeft
De grootte van je ontwikkelteam is een van de belangrijkste factoren in deze afweging. Een klein team werkt meestal het prettigst met een monoliet, terwijl een groter team met meerdere parallelle ontwikkelaars meer profijt heeft van een modulaire opzet, simpelweg omdat ze dan minder snel in elkaars weg lopen.
Wat dit voor je hostingkosten betekent
De architectuurkeuze werkt ook door in je hostingkosten. Een monoliet is meestal goedkoper om te hosten in de beginfase, omdat je een simpele opzet nodig hebt. Een modulaire architectuur vraagt meer beheer en dus meer hostingbudget, wat een extra reden is om deze stap pas te zetten als de groei het daadwerkelijk vereist.
Bouw voor de fase waarin je nu zit
De beste architectuurkeuze is niet de meest toekomstbestendige op papier, maar de keuze die past bij de fase waarin je start-up nu zit. Bespreek deze keuze in ieder geval een keer expliciet met je ontwikkelpartner, ook als je zelf nog geen directe noodzaak voelt om iets te veranderen. Bespreek deze afweging minstens een keer per jaar opnieuw met je team, ook als er op het eerste gezicht geen directe aanleiding voor lijkt te zijn. Hoe je ook kiest, blijf deze afweging als een levend onderwerp behandelen in plaats van een besluit dat je één keer neemt en daarna nooit meer herziet. Een architectuurkeuze is nooit definitief, en dat is precies waarom het de moeite waard is om er regelmatig bewust naar te blijven kijken. Wil je hierover sparren? Plan een vrijblijvende sparsessie of download het volledige handboek voor meer praktijkvoorbeelden.