Wie man 2026 einen SaaS-Stack wählt: Monorepo, Next.js, NestJS, MongoDB

Die Frage „welchen Stack soll ich verwenden“ ist schwieriger, nicht einfacher geworden, weil die Antwort davon abhängt, was Ihr Team bereits kennt und womit Ihr Käufer zu integrieren bereit ist. Es gibt keinen objektiv besten Stack. Es gibt einen Stack, der für Ihre spezifische Kombination aus Team, Käufer und Zeitplan am besten ist.

Monorepo vs. Polyrepo

Zwei Jahre Betrieb eines pnpm-Monorepos bei 2Run geben für unseren Fall eine klare Antwort: Monorepo.

Die Gewinne sind konkret: geteilte TypeScript-Typen zwischen dem NestJS-Backend und dem Next.js-Frontend (kein „die API gibt X zurück“-Raten mehr), eine CI-Pipeline, ein Satz Linting-Regeln, ein Ort, an dem eine Security-Baseline über beide Apps hinweg erzwungen wird.

Die Verluste sind ebenfalls konkret: Config-Drift, eine CI, die bei jedem Merge beide Apps baut, auch wenn sich nur eine geändert hat, ein Tooling-Setup, das eine Woche braucht, um sauber zu landen. Für ein Team von ein bis zwei Ingenieuren ist ein Polyrepo einfacher.

Die Entscheidungsregel:

• Monorepo, wenn Sie zwei oder mehr Frontend-/Backend-Apps haben, die Typen, Auth und einen Release-Takt teilen.
• Polyrepo, wenn Sie eine App und eine API haben oder wenn Sie mehrere Apps haben, die nichts teilen. Die Einrichtungskosten eines Monorepos sind real, und auf dieser Skala holen Sie sie nicht zurück.

Next.js (App Router) – wann es passt

Next.js ist ein Default für unsere B2B-Web-Apps aus drei Gründen:

• Eingebautes i18n-Routing. Das (routes)/[locale]-Segmentmuster ist genau, was wir für ein Fünf-Sprachen-Produkt brauchen. Die Middleware-Story für Locale-Erkennung und Rewrites ist ausgereift.
• Server-Komponenten für Marketing-Flächen. Eine Landingpage, die MDX-Content, CMS-gestützte Daten und ein kleines interaktives Widget kombiniert, ist eine Datei mit drei Komponenten. Die Default-React-Muster brauchen mehr Kleber.
• Eine Security-Baseline, die meistens sofort stimmt. HSTS, Frameguard, Referrer-Policy und CSP-Defaults sind über Middleware und Headers-Config abstimmbar. Wir schreiben dennoch eine gehärtete Middleware (siehe den Security-Hardening-Beitrag), aber wir bauen nicht ab Null.

Der Preis: Bundle-Größe, die Server-/Client-Grenze des App-Router ist eine echte Lernkurve, und die Data-Cache-Semantik in Next 16 erfordert bewusstes Management, um veraltete Reads zu vermeiden.

NestJS – wenn Sie Struktur wollen

NestJS ist nicht das einfachste Backend-Framework. Es ist das, das nach unserer Erfahrung am besten skaliert. Der Grund: Die Modul-/Provider-/Controller-Struktur zwingt Sie, früh Bounded Contexts, Dependency Injection und einen Request-Lifecycle zu definieren. Das Muster überträgt sich auf jedes Framework, das Sie als Nächstes verwenden.

Drei konkrete Gewinne:

• Auth ist ein Modul, keine Route. Tauschen Sie das Auth-Modul aus, ohne die konsumierenden Routes zu berühren.
• Guards und Interceptors sind erstklassig. Rollenbasierte Zugriffskontrolle, Rate Limiting und Request-Logging komponieren sauber.
• Swagger-Generierung ist eine Config-Zeile. API-Dokumentation bleibt im Lockstep mit dem Code.

Der Preis: Die Dateianzahl ist höher als bei Express, die Lernkurve steiler als bei Fastify, und die dekoratorbasierte Metadaten haben scharfe Kanten bei generischen Typen.

MongoDB – für Dokumente, nicht für Joins

MongoDB ist die richtige Wahl, wenn das Datenmodell natürlich dokumentförmig ist: Blog-Beiträge, Content-Seiten mit gemischten Metadaten, nutzergenerierter Content mit flexiblen Schemata, Katalogdaten mit Attributen, die nach Kategorie variieren.

MongoDB ist die falsche Wahl, wenn das Datenmodell stark relational ist: ein Finanz-Buch, ein Multi-Tenant-Analytics-Warehouse, ein Berechtigungssystem mit Viele-zu-Viele-Kanten. Dafür verwenden wir Postgres.

Die Falle: Jedes Team probiert MongoDB zuerst und will dann auf halbem Weg Joins. Machen Sie das Datenmodell ehrlich, bevor Sie sich festlegen. Wenn Sie es noch nicht wissen, starten Sie mit Postgres – von MongoDB später wegzumigrieren ist schwerer als von Postgres.

Was wir 2026 für einen B2B-SaaS wählen

Für einen B2B-SaaS mit Fünf-Sprachen-Unterstützung, browserbasierten Produktflächen und Integration in EU-Compliance-Regime:

• pnpm-Monorepo mit apps/web und apps/backend.
• Next.js (App Router) im Frontend mit next-intl für Locales.
• NestJS im Backend mit modularem Auth, Content und Übersetzungsmodulen.
• MongoDB für Content, Jobs und produktförmige Daten, Postgres für Abrechnung und Buch.
• Redis für Cache, Pub/Sub und Rate-Limit-Zustand.
• MinIO (S3-kompatibel) für Dateispeicherung mit einem Proxy-Endpunkt, der nie Bucket-URLs preisgibt.

Das ist nicht die einzige gültige Kombination. Es ist die, die wir zweimal ausgeliefert, zweimal bezahlt und auf die wir wieder wetten würden.