One Codebase, Five Products: The Monorepo Pattern

TL;DR. AI-native teams in 2026 are shipping multiple micro-SaaS products from a single monorepo because shared agents, shared infrastructure, and shared evals compound across products in a way that polyrepo architectures can not match. Nx now ships a nx configure-ai-agents command that installs CLAUDE.md, AGENTS.md, and an MCP server in one shot. Turborepo's content-aware caching means agent-driven changes ship in seconds. This post is the case for the SaaS-factory monorepo, when Turborepo wins, when Nx wins, and the failure modes I have hit running this pattern.

What changed in 2026

The traditional argument against monorepos was cognitive load: large codebases overwhelm individual engineers who only need a small piece. That argument was strong when humans were doing the navigation. Coding agents do not have that constraint. Claude Code, Cursor, and Codex traverse a monorepo with the same fluency they traverse a small project. The cognitive-load argument inverted.

What stayed true: shared infrastructure compounds. One auth layer. One billing module. One observability stack. One agent harness. When you ship the second product, you do not rebuild any of these. By the fifth product, the marginal cost of launching is hours, not weeks.

Pieter Levels has been demonstrating this pattern for a decade. Five micro-SaaS apps, one PHP codebase, seven-figure compounding revenue. The 2026 version is the same pattern with TypeScript, Next.js, and AI agents.

The case for the SaaS factory

Three structural advantages that compound for AI-native teams.

1. Agents need to read the whole graph. A coding agent fixing a bug in product A often needs context from shared module B. In a polyrepo, this requires switching repos, re-loading context, fighting with tool boundaries. In a monorepo, it is one navigation. Nx's Polygraph feature creates a unified dependency graph so AI agents can coordinate changes across repos. The monorepo skips the problem entirely.

2. Shared evals and observability. The agent harness running product A's customer-support flow can share the eval suite with product B's. Same prompts, same traces, same regressions surfaced once. This is the per-component eval pattern at codebase scale.

3. One deploy pipeline. The CI/CD that ships product A also ships product B. The self-healing patterns apply across all products. The infrastructure investment amortizes faster.

The combination produces the SaaS-factory pattern: one codebase, shared infrastructure, multiple products. The marginal cost of product N is dramatically lower than product 1.

Turborepo vs Nx in 2026

The two dominant tools have diverged. Pick based on team shape.

Turborepo wins when:

Team is 1 to 10 engineers
Stack is JavaScript / TypeScript first
Priority is fast cached builds with minimal config
Vercel deployment is the target

Turborepo's content-aware hashing re-runs only what changed and reuses cached outputs across machines. For a small AI-native team, the configuration-to-value ratio is excellent.

Nx wins when:

Team is 30+ engineers, or planning to be
Stack is multi-language (TypeScript + Python + Go)
AI-agent integration is a first-class need
Cross-repo coordination matters

The 2026 differentiator is Nx's AI integration. Nx Cloud's Polygraph creates a synthetic monorepo across separate repos so AI agents see the unified graph without code movement. nx configure-ai-agents installs the MCP server, agent skills, and project memory files in one command.

For a small AI-native team starting fresh, Turborepo is the right call. For a team scaling past 30 engineers or coordinating across multiple repos, Nx earns its complexity.

Architecting a SaaS factory

A working monorepo I have shipped against, Turborepo-style:

apps/
  product-a/        # Customer-facing SaaS A
  product-b/        # Customer-facing SaaS B
  product-c/        # Internal admin
  marketing-site/   # Public marketing
packages/
  ui/               # Shared design system
  auth/             # Shared auth (better-auth or similar)
  billing/          # Shared Stripe + Lago
  agents/           # Shared agent harness
  evals/            # Shared eval suite
  db/               # Shared Postgres + pgvector
  ai/               # Shared model gateway
infra/
  cloudflare/       # Worker bindings
  hetzner/          # Self-hosted services
docs/
  AGENTS.md         # Top-level agent rules

The pattern: anything reusable lives in packages/. Anything customer-facing lives in apps/. The agent harness, the eval suite, and the model gateway are all shared. Each product imports what it needs.

A new product launch: clone the smallest existing product, change the brand and the routes, wire up the product-specific schema. Shared everything else. First deploy in hours, not weeks.

What goes wrong

Three failure modes I have hit. Pre-empt them.

Shared package thrashing. A change to packages/ui rebuilds every app that imports it. If three apps depend on UI and you make 10 UI changes a day, you have 30 rebuilds. Fix: aggressive caching (Turborepo or Nx remote cache) plus careful versioning of shared packages. Treat them like internal libraries, not free-for-all.

Hidden coupling. Shared modules drift toward special-casing. Product A needs a tweak in auth, gets it via a flag. Product B needs a different tweak, gets a different flag. Three flags later the auth module is unmaintainable. Fix: a hard rule that shared packages do not contain product-specific branches. If a feature is per-product, it lives in the product's own code.

Build-time blow-up. A naive monorepo builds everything on every commit. CI takes 20 minutes. Engineers stop running the full build. Fix: incremental builds (Turborepo handles this natively, Nx with task pipeline configured). Only build what changed.

The agent angle

The pattern that compounds in 2026 specifically:

One AGENTS.md at the root. Universal rules. Architecture invariants. Taste rules.
Per-app AGENTS.md. Product-specific overrides. Stack quirks. Domain context.
Per-package SKILL.md. Reusable skills for shared modules (release process, schema migrations, eval runs).

The agent reading the monorepo navigates this hierarchy the same way a senior engineer would. The constraints compose. The result: an agent that ships consistent code across products without re-explaining the rules each session.

This pattern is what authoring constraints looks like at SaaS-factory scale. The senior engineer's job is the architecture documents. The agent's job is the implementation.

When the monorepo is wrong

Honest list.

Different runtime profiles. A real-time game server and a billing dashboard do not belong in the same monorepo. Different deploy targets, different latency profiles, different runtime stacks.
Genuinely separate teams with separate businesses. If product A and product B are run by different orgs that should not see each other's code, they are different repos. The monorepo argument is for shared teams, not just shared codebases.
Compliance boundaries. A SOC 2 boundary, a HIPAA boundary, or an FDA boundary often forces repo separation for audit. Worth checking before you commit to one repo.

Where this connects

A SaaS factory works because the agent harness reads across products. The shared eval suite catches regressions before they ship. The self-healing CI/CD applies the same recovery patterns across the whole graph. The stack is shared infrastructure (Postgres + pgvector, n8n, PostHog) running once and serving every product.

The pattern is what enables a solo founder to ship the work of fifteen.

The takeaway

The monorepo argument flipped in 2026 because the cognitive-load critique only applied to humans navigating code. Agents do not have that limitation. The structural advantages (shared agents, shared evals, shared infrastructure, one deploy pipeline) compound for AI-native teams. Turborepo for fast builds at small scale. Nx for unified-graph AI integration at larger scale. Either choice is materially better than five separate repos for a team that is shipping multiple AI-driven products.