How to Choose a SaaS Stack in 2026: Monorepo, Next.js, NestJS, MongoDB

The "what stack should I use" question has become harder, not easier, because the answer depends on what your team already knows and what your buyer is willing to integrate with. There is no objectively best stack. There is a stack that is best for your specific combination of team, buyer, and timeline.

Monorepo vs polyrepo

Two years of running a pnpm monorepo at 2Run gives a clear answer for our case: monorepo.

The wins are concrete: shared TypeScript types between the NestJS backend and the Next.js frontend (no more "the API returns X" guessing), one CI pipeline, one set of linting rules, one place to enforce a security baseline across both apps.

The losses are also concrete: shared config drift, a CI that builds both apps every merge even when only one changed, a tooling setup that takes a week to land correctly. For a team of one or two engineers, a polyrepo is simpler.

The decision rule:

• Monorepo if you have two or more frontend/backend apps that share types, share auth, and share a release cadence.
• Polyrepo if you have one app and one API, or if you have multiple apps that share nothing. The setup cost of a monorepo is real and you do not earn it back at this scale.

Next.js (App Router) — when it fits

Next.js is a default for our B2B web apps for three reasons:

• Built-in i18n routing. The (routes)/[locale] segment pattern is exactly what we need for a five-locale product. The middleware story for locale detection and rewrites is mature.
• Server components for marketing surfaces. A landing page that combines MDX content, CMS-backed data, and a small interactive widget is one file with three components. The default React patterns require more glue.
• A security baseline that is mostly right out of the box. HSTS, frameguard, referrer policy, and CSP defaults are tunable through middleware and headers config. We still write a hardened middleware (see the security-hardening post), but we are not building from zero.

The cost: bundle size, App Router's server/client boundary is a real learning curve, and the data-cache semantics in Next 16 require deliberate management to avoid stale reads.

NestJS — when you want structure

NestJS is not the simplest backend framework. It is the one that scales best in our experience. The reason: the module/provider/controller structure forces you to define bounded contexts, dependency injection, and a request lifecycle early. The pattern transfers to whatever framework you use next.

Three concrete wins:

• Auth is a module, not a route. Replace the auth module without touching the routes that consume it.
• Guards and interceptors are first-class. Role-based access, rate limiting, and request logging all compose cleanly.
• Swagger generation is a config line. API documentation stays in lockstep with the code.

The cost: the file count is higher than Express, the learning curve is steeper than Fastify, and the decorator-based metadata has sharp edges around generic types.

MongoDB — for documents, not for joins

MongoDB is the right choice when the data model is naturally document-shaped: blog posts, content pages with mixed metadata, user-generated content with flexible schemas, catalog data with attributes that vary by category.

MongoDB is the wrong choice when the data model is heavily relational: a financial ledger, a multi-tenant analytics warehouse, a permissions system with many-to-many edges. We use Postgres for those.

The trap: every team tries MongoDB first, then realizes they want joins halfway through. Get the data model honest before committing. If you do not know yet, start with Postgres — it is harder to migrate away from MongoDB than from Postgres later.

What we choose for a B2B SaaS in 2026

For a B2B SaaS with five-language support, browser-based product surfaces, and integration into EU compliance regimes:

• pnpm monorepo with apps/web and apps/backend.
• Next.js (App Router) on the frontend with next-intl for locales.
• NestJS on the backend with modular auth, content, and translation modules.
• MongoDB for content, jobs, and product-shaped data, Postgres for billing and ledger.
• Redis for cache, pub/sub, and rate-limit state.
• MinIO (S3-compatible) for file storage with a proxy endpoint that never exposes bucket URLs.

This is not the only valid combination. It is the one we have shipped twice, paid for twice, and would bet on again.