Monorepo vs Polyrepo in 2026: De keuze die blijft hangen

De monorepo versus polyrepo vraag komt op voor elk nieuw project. Het antwoord bepaalt maanden van CI/CD-setup, refactoring overhead, en team access control. Voor de meeste solo developers die een product bouwen met gedeelde code zijn de voordelen en nadelen van monorepo voordelen nadelen duidelijk: monorepo is de juiste standaard in 2026. Niet omdat het de trendy keuze is, maar omdat het de publishing ceremonie wegneemt die polyrepos opleggen zodra twee packages met elkaar moeten praten. Het werkelijke verschil monorepo polyrepo speelt zich af in de praktijk van dagelijkse development. Als je services volledig onafhankelijk zijn en echt nooit code zullen delen, is polyrepo eenvoudiger. Elk ander geval is context.

Het is 22 uur, en je hebt een paar uur code-tijd voor je bent.

Echt waargebeurd. Je hebt een nieuw project in wording: een backend API, een package met gedeelde TypeScript types, en een frontend dashboard die onvermijdelijk beide zal consumeren. Twee tabs open. De cursor knippert.

De meeste posts over dit onderwerp zijn geschreven voor engineeringteams van twintig man met een dedicated DevOps engineer die ervan geniet Bazel in te stellen. Dit artikel is voor builders die deze keuze moeten maken voor de eerste commit, want als je zes maanden later restructureert, als je echte gebruikers hebt en een CI-pipeline die je spieren hebben onthouden, is dat het soort ding dat de momentum van je side project voor goed doodmaakt. Voor developers in Nederland, België en andere West-Europese markten waar veel indie hackers werken, is deze keuze cruciaal omdat je resources gelimiteerd zijn. Je hebt geen luxe van een DevOps team.

Wat een monorepo echt voor je doet (niet de leerboekversie)

De standaard pitch is "een repo, gedeelde dependencies, atomaire changes." Dat klopt allemaal. Maar het deel dat werkelijk dagelijks uitmaakt voor een solo builder is concreter: je hoeft packages niet te publiceren om ze lokaal te gebruiken.

In een polyrepo-setup, als shared-utils een fix nodig heeft die ook api-service raakt, publiceer je ofwel een nieuwe versie van shared-utils, update je de dependency in api-service, wacht je tot CI voorbij gaat, en deploy je dan. Anders val je terug op npm link hacks die werken tot ze ineens niet meer werken midden in de sprint. In een monorepo met workspaces verander je simpelweg de code, en elk package dat het importeert ziet de verandering meteen. Geen publishing ceremonie.

Hier is wat dat eruit ziet met pnpm workspaces, wat minimale configuratie overhead toevoegt:

/packages
  /shared-types      <- direct geimporteerd door api en web
  /api
  /web
package.json         <- workspace root met "workspaces" veld

// api/package.json
{
  "dependencies": {
    "@myapp/shared-types": "workspace:*"
  }
}

Geen publicatie. Geen version bumping tijdens development. workspace:* lost op naar het lokale package, en TypeScript's project references geven je incrementele compilatie over de hele grafiek.

Het tweede werkelijke voordeel: cross-package refactoring die in een PR landt. Hernoem je een interface in shared-types? TypeScript vertelt je elke consumer die broken is, in dezelfde codebase, in dezelfde editor sessie. In een polyrepo hernoem je het in repo A, publiceer je een nieuwe versie, en ontdek je de breakage in repo B drie dagen later als een collega npm install draait en de types passen niet meer bij de runtime.

Het derde voordeel, wat solo developers onderschatten: een plaats voor tooling configuratie. Een .eslintrc, een prettier.config.js, een CI workflow file. Kleine besparingen per verandering, maar ze groeien enorm uit over maanden van iteratie. Voor independent developers die zelf alles beheren, telt dit effect zwaar mee.

Het is waard te noemen wat een monorepo NIET voor je doet: het maakt services niet minder gekoppeld. Als je services werkelijk onafhankelijk zijn en je zet ze toch in een monorepo, heb je coordinatie overhead toegevoegd zonder return op investeringen. De voordelen van de monorepo realiseren zich alleen wanneer de services werkelijk code delen of samen moeten veranderen. De repo-structuur moet de dependency-structuur weerspiegelen, niet een opleggen.

Wanneer polyrepo zijn plaats verdient

Polyrepo is geen fout. Het is de juiste keuze voor specifieke situaties, en doen alsof dat niet zo is, is hoe je eindigt met een 40-service monorepo die 25 minuten nodig heeft om te clonen.

De duidelijkste case: services met werkelijk verschillende ownership, release cycles, of compliance requirements. Als je billing service PCI-scoped is en je marketing site niet, dan houdt gescheiden repositories access control, audit logs, en blast radius schoon gescheiden. Dat is geen operationele overhead. Dat is het feature. In dit geval kun je polyrepo rechtvaardigen aan jezelf en aan external partners zonder compromissen op veiligheid of werkingsstructuur.

Polyrepo wint ook wanneer je deel van je codebase open-source. Een dedicated public repo laat externe contributors forken en PR zonder je private infrastructuur in scope te trekken. GitHub's repository-level permission model geeft je geen schone path-based access isolation op schaal. Een aparte repo handelt dat correct af.

En voor pure microservices met volledig verschillende tech stacks: een Go service en een React Native app die letterlijk niks op code-niveau delen, voegt een monorepo coordinatie cost toe zonder het voordeel te leveren. Als er geen gedeelde packages zijn, is er niks om te delen.

De eerlijke versie hiervan: de meeste indie-projecten die met een polyrepo starten, betreuren het later, niet omdat polyrepo slechte architectuur is, maar omdat ze overschatten hoe onafhankelijk de delen zouden blijven. De frontend heeft altijd een type van de backend nodig. De worker heeft altijd een utility van de API nodig. Twee repos worden vier PRs voor elk feature. Dit probleem zie je vooral als je solo werkt.

De CI/CD-kost die niemand noemt tot het je rekening raakt

Monorepos hebben een werkelijke operationele kost: als je CI naief alles draait op elke commit, betaal je in tijd en geld voor builds en tests die niks te maken hebben met wat je veranderde.

Duw een CSS-tweak naar het web package. CI draait de volledige test suite voor api, worker, en shared-types. Dat is zes minuten GitHub Actions compute voor een kleurverandering. Op schaal wordt dit CI-queues die je heel team blokkeren. Voor een solo dev kost dit direct geld uit eigen zak. Elke unnecessaire minuut buildtijd is elektriciteit en cloudresources die je waard bent.

De oplossing bestaat, maar vereist deliberate setup: build orchestration tools die je dependency graph begrijpen. Turborepo en Nx lossen dit allebei op. De turbo.json van Turborepo definieert een pipeline waar elk task alleen draait voor packages met veranderde inputs:

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "cache": true
    }
  }
}

Met remote caching ingeschakeld (gratis op Vercel's Turborepo Cloud tier voor kleine teams), is een cache hit op een ongewijzigd package onmiddellijk, geen rebuild, geen retest. Voor een solo dev op een side project houdt dit CI onder twee minuten op de meeste pushes zodra de build artifacts warm zijn. Dit scheelt niet alleen tijd, maar ook je elektriciteitsrekening.

De kost: je moet Turborepo of Nx leren voor je het nodig hebt, niet daarna. Het is ruwweg een halve dag setup. Als je het overslaat en CI laat aangroeien, zal monorepo CI vertragen tot het punt waar je de hele architecturale keuze in twijfel trekt, en dat is meestal wanneer developers besluiten dat polyrepo toch gelijk had, als het werkelijke probleem gewoon een ontbrekend config-bestand was. De turborepo instellen kost even moeite, maar de return is direct voelbaar.

Hoe AI coding tools de wiskunde van dit debat hebben veranderd

Tot recent was een werkelijk argument voor polyrepo cognitive load: kleinere repos zijn makkelijker na te denken omdat ze geisoleerd zijn. Context-switch naar een nieuwe service, zie alleen wat relevant is voor die service. Het argument was legitiem.

AI coding tools verschuiven die berekening. Als je met Cursor, Claude Code, of GitHub Copilot werkt, ziet de tool je volledige codebase in context. Het ziet cross-service dependencies, begrijpt welke interface door welke service wordt geconsumeerd, en kan een hernoemd veld volgen door elke consumer zonder dat je het mentale model zelf moet houden. Het "geisoleerde repo is makkelijker te begrijpen" argument verzwakt significant wanneer je AI assistant toch de hele dependency grafiek in context houdt.

Een concreet voorbeeld: in een polyrepo-setup, als je een AI assistant vraagt een API-endpoint te refactoren dat ook een gedeelde type raakt, kan het typisch beide repos niet in een sessie zien. Je doet de coordinatie handmatig, wat precies de overhead is die een monorepo zou moeten elimineren. In een monorepo is dezelfde refactor een conversatie.

Dit flipt de beslissing niet volledig. Maar het verwijdert een van de historische rechtvaardigingen voor polyrepo voor kleine teams en solo developers, en buigt de standaard iets verder naar monorepo wanneer de code werkelijk gekoppeld is. Voor indie hackers die met AI tools werken is dit een game-changer.

Drie signalen dat je nu moet splitsen

Je bent begonnen met een monorepo. Prima. Maar hier zijn de werkelijke signalen dat de split de juiste call is geworden:

Access control wordt load-bearing. Een contractor heeft frontend-toegang nodig, niet backend. Een partner integration team moet je API-schema lezen maar niks proprietary. GitHub's Codeowners kan beperken wie welke paths kan reviewen, maar het beperkt read-toegang niet. Als read-isolatie uitmaakt voor compliance of security, zijn aparte repos het schone antwoord. Codeowners gymnastics kan nooit repository-level permissions volledig vervangen. Dit is vooral relevant als je later externe developers aanneemt of met partners samenwerkt.

CI failures in de ene service blokkeren deployment in een ongebonden andere. Als een gebroken test in payment-service een hotfix die je moet shippen in marketing-site blokkeert, creert je monorepo coupling die je codebase niet heeft. Dit is het klassieke symptoom van een monorepo die niet goed geconfigureerd is. Ofwel de build configuratie moet fixing (task scoping met Turborepo lost dit op), ofwel horen de twee services werkelijk niet in dezelfde repo. Zeker voor productie environments moet je dit voorkomen.

Een deel gaat open-source en een niet. Dit is de schoonste split case. Extract het open-source stuk naar een eigen public repo. Gemengde public/private code in een GitHub monorepo is werkelijk pijnlijk: je zou een aparte organisatie nodig hebben of een manual pruning process dat permanente maintenance overhead creert.

De praktische setup waar de meeste builders op uitkomen

Het antwoord waar ervaren developers op uitkomen: een monorepo per product domein, niet "een monorepo voor alles wat je ooit hebt gebouwd" en niet "een repo per package."

Als je een SaaS bouwt met een web frontend, een API, en een gedeelde type library, dat is een product. Zet het in een monorepo. Dit soort setup profiteert direct van pnpm workspaces en shared configuration. Als je ook een open-source CLI utility onderhoudt die andere projecten gebruiken, dat is een aparte repo met een ander publiek en release cycle. De scheidslijn is simpel: shared code betekent shared repo.

De fout is de monorepo/polyrepo keuze als ideologisch behandelen. Het is niet "monorepo teams" versus "polyrepo teams." Het is een structurele beslissing op basis van drie vragen: Wat is de dependency grafiek tussen je services? Wie heeft toegang nodig tot wat, en maakt isolatie uit? Wat is je tolerantie voor CI/CD setup complexity?

Voor side projects specifiek: begin met een monorepo met pnpm workspaces (npm workspaces werken ook, gewoon minder ergonomisch). Voeg Turborepo alleen toe wanneer je CI regelmatig 4+ minuten raakt en je genoeg data hebt om te zien wat versneld moet worden. Split in een aparte repo alleen als je een werkelijke reden hebt: open-source, access control, compliance, of een partner team met ander release cadence. Niet omdat het architecturaal schoner voelt. Bij dit soort keuzes geldt het klassieke adagium: optimize later, ship now. Te veel architecten bouwen voor problemen die ze nog niet hebben.

Het monorepo versus polyrepo debat is een van die keuzes waar het juiste antwoord voor de meeste solo developers hetzelfde is: begin eenvoudig, optimeer wanneer de specifieke wrijving verschijnt. De repository architectuur softwareontwikkeling is geen abstracte kwestie maar een praktische vraag die je medio project beantwoordt, niet aan het begin. De meeste succesvolle indie projecten starten met monorepo, pnpm workspaces, en geen overengineering. Pas later, als je werkelijk het probleem voelt, voeg je build orchestration toe. De cursor knippert nog steeds. Ship de eerste commit.