Hoe kies je een SaaS-stack in 2026: Monorepo, Next.js, NestJS, MongoDB

De vraag "welke stack moet ik gebruiken" is moeilijker geworden, niet makkelijker, omdat het antwoord afhangt van wat je team al weet en wat je koper bereid is mee te integreren. Er is geen objectief beste stack. Er is een stack die het beste is voor jouw specifieke combinatie van team, koper en tijdlijn.

Monorepo vs polyrepo

Twee jaar een pnpm-monorepo draaien bij 2Run geeft een duidelijk antwoord voor ons geval: monorepo.

De wins zijn concreet: gedeelde TypeScript-typen tussen de NestJS-backend en de Next.js-frontend (geen "de API geeft X terug" giswerk meer), één CI-pipeline, één set linting-regels, één plek om een security-baseline over beide apps af te dwingen.

De verliezen zijn ook concreet: gedeelde config-drift, een CI die beide apps bij elke merge bouwt zelfs als er maar één veranderde, een tooling-setup die een week kost om correct te landen. Voor een team van één of twee ingenieurs is een polyrepo eenvoudiger.

De beslisregel:

• Monorepo als je twee of meer frontend/backend-apps hebt die typen delen, auth delen en een release-cadans delen.
• Polyrepo als je één app en één API hebt, of als je meerdere apps hebt die niets delen. De setup-kosten van een monorepo zijn reëel en die verdien je niet terug op deze schaal.

Next.js (App Router) — wanneer het past

Next.js is een standaardkeuze voor onze B2B-webapps om drie redenen:

• Ingebouwde i18n-routing. Het (routes)/[locale]-segmentpatroon is precies wat we nodig hebben voor een product met vijf talen. Het middleware-verhaal voor locale-detectie en rewrites is volwassen.
• Server components voor marketingoppervlakken. Een landingspagina die MDX-inhoud, CMS-backed data en een kleine interactieve widget combineert is één bestand met drie componenten. De standaard React-patronen vereisen meer lijm.
• Een security-baseline die grotendeels out-of-the-box klopt. HSTS, frameguard, referrer-policy en CSP-standaarden zijn afstelbaar via middleware en headers-config. We schrijven nog steeds een geharden middleware (zie de security-hardening-post), maar we bouwen niet vanaf nul.

De kosten: bundle-formaat, de server/client-grens van de App Router is een echte leercurve, en de data-cache-semantiek in Next 16 vereist doelbewust beheer om stale reads te vermijden.

NestJS — wanneer je structuur wilt

NestJS is niet het eenvoudigste backend-framework. Het is in onze ervaring het framework dat het beste schaalt. De reden: de module/provider/controller-structuur dwingt je vroeg om bounded contexts, dependency injection en een request-levenscyclus te definiëren. Het patroon draagt over naar welk framework je daarna ook gebruikt.

Drie concrete wins:

• Auth is een module, geen route. Vervang de auth-module zonder de routes die hem consumeren aan te raken.
• Guards en interceptors zijn first-class. Role-based access, rate limiting en request-logging componeren allemaal netjes.
• Swagger-generatie is één configregel. API-documentatie blijft in lockstep met de code.

De kosten: het bestandenaantal is hoger dan Express, de leercurve is steiler dan Fastify, en de op decorator-gebaseerde metadata heeft scherpe randen rond generieke typen.

MongoDB — voor documenten, niet voor joins

MongoDB is de juiste keuze wanneer het datamodel van nature document-shaped is: blogposts, contentpagina's met gemengde metadata, user-generated content met flexibele schema's, catalogusdata met attributen die per categorie variëren.

MongoDB is de verkeerde keuze wanneer het datamodel sterk relationeel is: een financiële ledger, een multi-tenant analytics-warehouse, een permissiesysteem met veel-op-veel-randen. Wij gebruiken Postgres voor die.

De val: elk team probeert eerst MongoDB en realiseert zich halverwege dat ze joins willen. Wees eerlijk over het datamodel voordat je commit. Als je het nog niet weet, begin met Postgres — het is lastiger om weg te migreren van MongoDB dan later van Postgres.

Wat we kiezen voor een B2B-SaaS in 2026

Voor een B2B-SaaS met ondersteuning voor vijf talen, browsergebaseerde productoppervlakken en integratie in EU-compliance-regimes:

• pnpm monorepo met apps/web en apps/backend.
• Next.js (App Router) aan de frontend-kant met next-intl voor locales.
• NestJS aan de backend-kant met modulaire auth-, content- en translation-modules.
• MongoDB voor content, jobs en product-shaped data, Postgres voor facturering en ledger.
• Redis voor cache, pub/sub en rate-limit-state.
• MinIO (S3-compatibel) voor bestandsopslag met een proxy-eindpunt dat nooit bucket-URL's blootlegt.

Dit is niet de enige geldige combinatie. Het is er een die we twee keer hebben uitgerold, twee keer hebben betaald en waarop we opnieuw zouden inzetten.