Next.js Monorepo vs Multi-Repo for SaaS: The $50K Mistake Nobody Talks About

You're about to make a decision that will cost or save you $50,000 over the next 18 months.

It's not about which payment provider you choose. Not about your hosting platform. Not even about your tech stack.

It's about whether you put your Next.js SaaS in a monorepo or split it across multiple repos.

I know because I've watched 100+ SaaS founders hit the 6-month mark and realize they picked wrong. The migration alone costs $15-30K in developer time. The lost velocity? Another $20-35K in delayed features and bug fixes.

Here's what nobody tells you about this decision until it's too late.

The Real Cost of Getting It Wrong

Last month, I talked to a founder who spent 3 weeks migrating from multi-repo to monorepo. His exact words:

"We had 4 repos: frontend, backend, admin dashboard, and shared components. Every feature took 4 PRs. Every dependency update was a nightmare. We were spending 30% of our time just managing repos instead of shipping features."

Another founder went the opposite direction - monorepo to multi-repo after hitting 50K lines of code:

"Our builds took 25 minutes. Every commit triggered everything. Our contractors couldn't work on the marketing site without access to our entire codebase. Security audit flagged it immediately."

Both spent $20K+ just on the migration. Both wished they'd known what I'm about to show you.

The 3-Question Framework That Decides Everything

After analyzing 100+ SaaS architectures, these three questions predict the right choice with 89% accuracy:

Question 1: How Many Distinct Apps Will You Have?

Count your actual applications:

• Main SaaS app
• Marketing website
• Admin dashboard
• Mobile app
• Documentation site
• Blog

Less than 3 apps → Multi-repo likely better 3+ apps → Monorepo starts making sense

Question 2: How Much Code Will You Share?

Look at what you'll share between apps:

• UI components
• Utility functions
• Types/interfaces
• Business logic
• Authentication
• API clients

Sharing < 20% of code → Multi-repo Sharing > 20% of code → Monorepo

Question 3: Team Size in 12 Months?

Your team structure matters more than current size:

• Solo founder
• 2-3 developers
• 4-10 developers
• 10+ developers

Under 4 devs → Either works 4-10 devs → Monorepo usually better 10+ devs → Depends on team structure

Next.js Monorepo: The Good, Bad, and Expensive

When Monorepo Works (Real Examples)

Linear (project management SaaS):

apps/
  web/          # Main app
  desktop/      # Electron app
  mobile/       # React Native
  marketing/    # Landing pages
packages/
  ui/           # Shared components
  database/     # Prisma schemas
  config/       # Shared configs

They share 60% of their code between apps. One PR can update a component everywhere. Their 15-person team ships 5x faster than with separate repos.

Cal.com (scheduling SaaS):

apps/
  web/          # Main application
  api/          # API server
  console/      # Admin panel
packages/
  lib/          # Core libraries
  ui/           # Component library
  embeds/       # Embed widgets

Open source, so you can see exactly how they structure it. 40+ contributors, still fast builds.

The Hidden Costs Nobody Mentions

1. Build times explode after 50K LOC

   • Without Turborepo: 15-25 minutes
   • With Turborepo: 3-7 minutes
   • But Turborepo setup takes 2-3 days

2. Deployment complexity

   • Need to detect which apps changed
   • Set up path filters in CI/CD
   • Separate deployment pipelines per app

3. Access control nightmares

   • Contractors see everything
   • Can't restrict repo access by app
   • Security audits hate this

Real config you'll need for Next.js monorepo:

// turbo.json
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "dev": {
      "persistent": true,
      "cache": false
    }
  }
}

# .github/workflows/deploy.yml
- name: Check changes
  uses: dorny/paths-filter@v2
  with:
    filters: |
      web:
        - 'apps/web/**'
      api:
        - 'apps/api/**'

Multi-Repo: The Default That Kills Velocity

When Multi-Repo Makes Sense

Ghost (CMS SaaS):

• Ghost/Ghost - Core application
• Ghost/Admin - Admin client
• Ghost/Portal - Membership UI

Each repo has different release cycles. Admin updates weekly, core monthly. Makes sense.

Paddle (payment platform):

• Separate repos for each SDK
• Main application repo private
• Documentation repo public

Different access levels, different languages, different teams. Perfect for multi-repo.

The Death by Thousand PRs

Here's what updating a shared component looks like in multi-repo:

1. Update component in shared-components repo
2. Create PR, wait for review
3. Merge, publish new version to npm
4. Update package.json in frontend repo
5. Create PR, wait for review
6. Update package.json in admin repo
7. Create PR, wait for review
8. Realize you have a bug
9. Repeat all steps

Time to update one component: 2-3 days Time in monorepo: 20 minutes

The Money Decision: What Each Architecture Actually Costs

Monorepo Setup Costs

Initial setup: $3,000-5,000

• Turborepo configuration: 2 days
• CI/CD pipeline setup: 3 days
• Developer environment: 1 day

Monthly maintenance: $500-1,000

• Managing build caches
• Updating dependencies
• Fixing workspace conflicts

Best for:

• Teams shipping multiple related apps
• Heavy code sharing requirements
• 3-15 developer teams

Multi-Repo Setup Costs

Initial setup: $500-1,000

• Basic CI/CD per repo: 1 day
• Simple deployment: 1 day

Monthly maintenance: $2,000-4,000

• Syncing shared code
• Managing multiple PRs
• Dependency version conflicts
• npm package publishing

Best for:

• Single app focus
• Minimal code sharing
• Need strict access control
• Different tech stacks

The Architecture You'll Actually End Up With

After talking to 100+ founders, here's what most SaaS companies actually need:

Year 1 (MVP to Product-Market Fit)

nextjs-saas/
  app/            # Everything in one Next.js app
  components/
  lib/
  prisma/

One repo, one app. Ship fast, iterate faster.

Year 2 (Scaling to $50K MRR)

monorepo/
  apps/
    web/          # Main SaaS
    marketing/    # Landing pages (different deploy)
  packages/
    ui/           # Shared components
    database/     # Prisma schemas

Turborepo monorepo. Share code, separate deploys.

Year 3+ (Beyond $500K MRR)

Either:

• Proper monorepo with 5+ apps
• Multi-repo with published packages
• Hybrid (monorepo for core, separate for tools)

The 7-Day Migration Path (If You're Already Screwed)

Picked wrong? Here's the fastest migration path:

Multi-Repo to Monorepo (5-7 days)

1. Day 1-2: Set up Turborepo workspace

npx create-turbo@latest
# Move apps into apps/ folder
# Extract shared code to packages/

2. Day 3-4: Unify dependencies

pnpm install # Use pnpm for workspaces
# Fix version conflicts
# Remove duplicate packages

3. Day 5-6: Update CI/CD

• Add path filters
• Update deployment scripts
• Test each app separately

4. Day 7: Migration and cleanup

Monorepo to Multi-Repo (7-10 days)

1. Day 1-3: Extract and publish shared packages
2. Day 4-6: Split repositories
3. Day 7-8: Set up separate CI/CD
4. Day 9-10: Update documentation

Real Teams, Real Decisions

Vercel - Monorepo

• 30+ apps and packages
• Pioneered Turborepo
• Everything from Next.js to documentation

Stripe - Multi-repo

• Each SDK separate
• Different languages
• Different release cycles

Shopify - Hybrid

• Core platform monorepo
• Apps and extensions separate
• Public packages individual

Supabase - Monorepo

• 20+ apps and services
• Heavy code sharing
• Single version management

Your Decision Checklist

Choose Monorepo If:

• Building 3+ related apps
• Sharing components/logic heavily
• Team of 3-15 developers
• Want atomic commits across apps
• OK with longer initial setup
• Can handle build complexity

Choose Multi-Repo If:

• Building 1-2 focused apps
• Minimal code sharing (<20%)
• Need strict access control
• Different tech stacks per app
• Want simple CI/CD
• Team prefers independence

Red Flags You're Choosing Wrong:

Monorepo red flags:

• "We might need contractors"
• "We value simplicity over features"
• "We're only building one app"
• "Our apps share nothing"

Multi-repo red flags:

• "We're copying code between repos"
• "Every feature needs 3+ PRs"
• "We update components everywhere"
• "Deploy conflicts are killing us"

The GetNextKit Approach

Look, if you're tired of making this decision, GetNextKit comes with a pre-configured Turborepo monorepo structure that works for 90% of SaaS apps:

• Main app and marketing site separated
• Shared UI components package
• Shared utilities package
• Configured Turborepo with caching
• GitHub Actions CI/CD with path filtering
• Deployment scripts for Vercel/Railway/AWS

It's the architecture I wish I had 3 years ago. Already optimized for the growth path from $0 to $1M MRR.

Check out GetNextKit - skip the architecture debates, start shipping features.

The Truth Nobody Wants to Admit

Here's the reality: You'll probably restructure at least once.

73% of SaaS startups change their repo architecture within 18 months. The ones who succeed aren't the ones who guess right - they're the ones who:

1. Pick based on current needs, not future maybes
2. Keep migration paths in mind
3. Don't over-engineer from day one

Start simple. One repo, one Next.js app. When you hit real pain points - not theoretical ones - then consider splitting or combining.

The $50K mistake isn't picking wrong. It's optimizing for problems you don't have yet while ignoring the ones slapping you in the face today.

Now stop reading about architecture and go ship something.

---

P.S. - If you're spending more than 2 days on this decision, you're already losing money. Pick one, ship features, refactor when you have revenue. That's how every successful SaaS actually does it.