#Why micro frontends?

Before choosing any architecture, you should be honest about what problem you actually have. Micro frontends are best known for solving frontend development at team scale — but that's not their only use. They also shine when an application is inherently dynamic (composed from pieces at runtime) or when you want architecture-enforced modularity. Team scale is the most common driver, so we start there, then come back to the others.

#The root cause

A frontend monolith breaks down not because of the technology, but because of coordination. When three teams share one codebase, each deploy becomes a negotiation. The payments team's hotfix waits because the catalog team has an unfinished branch on main. Tests fail in the auth module because of changes in the product module that nobody told you about. A styling change from one team resets CSS variables used by another.

This is Conway's Law: your system's architecture mirrors your organization's communication structure. A monolith built by one team is fine. A monolith built by eight teams is a coordination bottleneck disguised as a technical problem.

Micro frontends move the architecture boundary to match the organizational boundary. Each team owns their vertical slice end-to-end — from API calls to rendered pixels — and deploys it independently.

#What actually changes with micro frontends

Deploys decouple. The payments team can push a fix at 2pm on a Friday without a deployment window or a conversation with the catalog team. Their work ships when it's ready.

Failures isolate. An uncaught error in the recommendations module doesn't bring down the checkout flow. Error boundaries around each pilet contain the blast radius.

Technology choices are local. One team can upgrade their React version. Another can experiment with Svelte. Neither affects the other's release.

Bundles are smaller per user. A user who never opens the admin dashboard never downloads that code.

Onboarding accelerates. New team members work in a smaller, scoped codebase instead of navigating a 200,000-line monolith.

#What doesn't change

Users still see one application. URLs still work. Navigation still works. The visual design still needs deliberate maintenance — that's what your design system is for, regardless of architecture.

And you can't eliminate coordination entirely. You still need agreement on:

• The Pilet API shape (what capabilities the shell exposes)
• Extension slot names and their parameter shapes
• How auth tokens are accessed by pilets
• How to handle cross-pilet navigation

The difference is these are interface contracts, not shared code commitments. Once agreed, they change rarely. Day-to-day work proceeds without inter-team friction.

#Beyond team scale

Two other situations justify micro frontends even without many teams:

Dynamic, composed applications. Some products are a composition: a portal whose modules differ per customer, a platform where third parties or other departments plug in features, an app that turns capabilities on and off at runtime. Here the runtime-composition model isn't overhead — it's the core requirement. You need to add, remove, and target modules without redeploying the host, which is exactly what a feed-driven micro frontend gives you.

Architecture-enforced modularity. Even a single team can choose micro frontends to make module boundaries physical rather than merely conventional. When each feature is an independently built, contract-bound module, "don't reach into another module's internals" stops being a code-review guideline and becomes something the architecture enforces. For long-lived systems where maintainability and clear seams matter, that discipline can be worth the overhead on its own.

#When simpler alternatives win

A shared component library solves the design consistency problem. If your main frustration is "our button looks different across pages," a design system fixes that without any runtime complexity.

A monorepo with strict module boundaries solves the code organization problem. Tools like Turborepo or Nx give you independent build caches, isolated package boundaries, and clean dependency graphs — while keeping a single deploy. The right answer for many mid-sized teams.

A well-structured single SPA is viable for teams up to approximately 8–10 engineers. Don't over-engineer until you feel the specific pain that over-engineering fixes.

#The honest summary

Micro frontends are the right answer when you have multiple teams who need to ship independently and have genuinely felt the coordination cost in production. They're the wrong answer when you're adopting them preemptively, when you have one team, or when your real challenge is code quality rather than release independence.

If micro frontends are right for you, the next question is which approach. Read Why Piral? to see how Piral addresses the common pain points.