---
title: "When Microfrontends"
description: "Learn the two primary use cases for microfrontends and the warning signs that your monolith needs splitting."
canonical_url: "https://vercel.com/academy/microfrontends-on-vercel/when-microfrontends"
md_url: "https://vercel.com/academy/microfrontends-on-vercel/when-microfrontends.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-04-09T04:12:56.008Z"
content_type: "lesson"
course: "microfrontends-on-vercel"
course_title: "Microfrontends on Vercel"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# When Microfrontends

# When Microfrontends Make Sense

Microfrontends are extremely useful but they add complexity. Don't adopt them unless they solve problems you actually have.

## Outcome

Evaluate whether microfrontends are the right solution for a given application by understanding the two primary use cases and recognizing warning signs.

## The Two Primary Use Cases

Microfrontends solve two specific problems:

### 1. Scaling Developer Experience

Your team has grown. Your codebase has grown. And now:

- **Build times exceed 5 minutes** - Every change triggers a full rebuild
- **Deploy coordination is painful** - Teams step on each other's releases
- **Onboarding takes weeks** - New developers can't understand the whole system
- **CI costs are climbing** - Full rebuilds for single-line changes

Vercel's own site hit this wall. After implementing microfrontends, they achieved **40%+ faster build times**.

### 2. Incremental Migration

You have a legacy application, maybe Create React App, an old Pages Router app, or something not even on Vercel, and you need to modernize without a risky rewrite.

Microfrontends let you:

- Carve out new routes into modern applications
- Keep legacy routes serving from the old system
- Migrate piece by piece over months
- Roll back instantly if something breaks

Notion is using this pattern right now: carving out sections of an old Pages Router application into new App Router apps, using feature flags for gradual rollout.

## Warning Signs Your Monolith Is Struggling

Before reaching for microfrontends, look for these symptoms:

| Symptom                     | What It Means                                     |
| --------------------------- | ------------------------------------------------- |
| Build time >5 min           | Too much code compiling for every change          |
| Teams blocked on each other | Shared codebase creates coordination overhead     |
| "Don't touch that file"     | Fear of breaking unrelated features               |
| Deploy windows              | Can only ship at certain times to avoid conflicts |
| Slow local dev              | `pnpm dev` takes forever to start                 |

If you're experiencing three or more of these, microfrontends might help.

## When NOT to Use Microfrontends

Microfrontends are wrong when:

- **Small team (fewer than 5 developers)** - The coordination overhead isn't worth it
- **Build times under 3 minutes** - Try Turbopack first
- **Tightly coupled UX** - Users frequently navigate between all areas
- **Single domain of expertise** - Everyone works on everything
- **Premature optimization** - "We might scale someday"

The overhead is real: duplicated middleware logic, more complex debugging, additional configuration. Don't pay that cost unless you're getting value back.

## Fast Track

1. Review the monolith audit checklist below
2. Identify which use case applies (DX scaling or migration)
3. Map your application's natural boundaries

## Hands-on Exercise 1.1

Audit the Acme Platform monolith to identify microfrontend boundaries.

**The "Before" State:**

You're working with a single Next.js application that serves everything:

```
acme-monolith/
├── app/
│   ├── page.tsx              # Landing page
│   ├── pricing/page.tsx      # Pricing
│   ├── about/page.tsx        # About
│   ├── docs/
│   │   ├── page.tsx          # Docs index
│   │   └── [slug]/page.tsx   # Docs pages
│   ├── app/
│   │   ├── page.tsx          # Dashboard
│   │   └── projects/page.tsx # Projects list
│   └── settings/
│       └── page.tsx          # User settings
├── middleware.ts             # Auth for /app/* and /settings/*
└── next.config.js
```

**Requirements:**

1. Identify three distinct user journeys in this application
2. Map which routes belong to each journey
3. Determine which routes require authentication
4. Identify shared components (header, footer, navigation)

**Audit Questions:**

- Do visitors to `/pricing` need the same code as users on `/app/projects`?
- If the docs team ships a typo fix, should it trigger a dashboard rebuild?
- Can the marketing team deploy independently from the dashboard team?

## Try It

After auditing, you should identify three natural boundaries:

**Marketing** (public, no auth):

- `/` - Landing page
- `/pricing` - Pricing
- `/about` - About

**Docs** (public, no auth):

- `/docs` - Documentation index
- `/docs/*` - Documentation pages

**Dashboard** (authenticated):

- `/app` - User dashboard
- `/app/*` - Dashboard routes
- `/settings/*` - User settings

## Done-When

- [ ] You can articulate the two primary microfrontend use cases
- [ ] You've identified three boundaries in the Acme monolith
- [ ] You understand which routes require authentication
- [ ] You know when NOT to use microfrontends

## The Cost-Benefit Question

Before proceeding, ask yourself:

> "Is the complexity of managing multiple applications worth the independence it provides?"

For Acme Platform, the answer is yes because:

1. Marketing, docs, and dashboard have distinct audiences
2. Different teams could own each area
3. A docs typo fix shouldn't require dashboard code to rebuild
4. Authentication only applies to dashboard routes

If your application doesn't have clear boundaries, microfrontends will create problems, not solve them.

## What's Next

You know the boundaries. Next: vertical vs horizontal microfrontends, and why we're starting with vertical.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)