Micro frontends get discussed as a frontend architecture. They are not, really. They are an organizational architecture that happens to be expressed in frontend code, and evaluating them on technical merit alone is how teams end up paying the cost without collecting the benefit.
What they actually buy
One thing: independent deployment by independent teams. A squad can ship its part of the experience without coordinating a release with five other squads.
Everything else people cite — technology heterogeneity, incremental migration, smaller bundles — is either a side effect, an illusion, or achievable more cheaply another way. Technology heterogeneity in particular is usually a liability dressed as a feature.
So the question is not "is this a good architecture." It is: is release coordination currently costing us more than the machinery would?
The cost is real and permanent
You take on shared dependency management across independently deployed units. Design-system versioning becomes a distributed problem. Cross-boundary state and navigation need deliberate contracts. Performance regressions get harder to attribute, because no single team owns the whole page. Local development gets slower and stranger.
None of that is fatal. All of it is permanent, and all of it grows with the number of boundaries you create.
The threshold
My rule of thumb: micro frontends start paying for themselves somewhere around five or six squads contending for the same release train, and only when those squads own genuinely separable customer journeys.
Below that, a well-structured monolith with clear module ownership gives you most of the isolation at a fraction of the operational cost. The honest test is whether teams are actually blocked on each other today — not whether they might be at some imagined future scale.
The failure mode I see most often is adopting the architecture in anticipation of growth that has not happened. You pay immediately; you collect later, if ever.
The decomposition test
Draw the boundaries you intend, then ask: can a squad ship a routine customer-facing improvement entirely inside one boundary? If the honest answer is "usually not", the boundaries are wrong and no amount of tooling will rescue them. That is a team-structure problem wearing an architecture costume.
Boundaries follow journeys, not layers
The decomposition that works is by customer capability — onboarding, checkout, search — because that is how work actually arrives. The decomposition that fails is by technology layer, or by page, or by whatever the existing folder structure suggests.
This is the same principle that governs squad design, which is not a coincidence. If your team boundaries and your architectural boundaries disagree, the architecture loses. Conway's Law is not a warning; it is a constraint you either design with or get designed by.
What I would tell someone considering it
- Count the blocked releases. If teams are not currently waiting on each other, you are solving a problem you do not have.
- Standardise ruthlessly. One framework version, one design system, one build toolchain. Heterogeneity is the cost, not the prize.
- Own performance centrally. Distributed ownership of a shared page means nobody owns the total. That needs a named owner from day one.
- Start with one boundary. Extract the most independent journey, live with it for a quarter, and see whether the coordination savings are real before extracting a second.
Used at the right size, micro frontends turn release coordination from a standing tax into a non-event. Used early, they turn a manageable codebase into a distributed systems problem you did not need to have.