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:

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.