When NOT to Use Microfrontends

Microfrontends are a solution to a specific problem: multiple teams needing to work on and deploy different parts of a large frontend independently. If that problem does not describe your situation, microfrontends will make your life significantly harder without delivering any benefit.

This is the article the ecosystem does not write often enough.

The hidden costs

Operational complexity

Every microfrontend is a separate deployable unit. That means separate CI pipelines, separate deployment targets, separate monitoring, and separate on-call runbooks. What was one system to reason about is now five.

When something goes wrong in production, you now have to ask: was it the shell? Was it the remote? Was it the version mismatch between the two? This class of failure mode does not exist in a monolith.

Version compatibility

Module Federation and similar runtime integration approaches require careful version alignment between host and remote. A remote that was compiled against React 18.2 may break when the host upgrades to React 18.3 — or it may not. You cannot know until runtime. You need contracts, versioning strategies, and integration tests that span application boundaries.

Increased bundle size

The shared config in Module Federation is designed to prevent duplicate libraries — but it is easy to misconfigure. A host and remote that both bundle their own copy of React will produce a significantly larger payload and cause subtle hook bugs that are extremely hard to diagnose.

Local development friction

Running five microfrontends locally means running five dev servers. Engineers spend time managing processes, ports, and environment variables just to see the application render correctly. Tools like concurrently or Nx's project graph help, but they add overhead.

Deployment orchestration

Independent deployability is the main selling point of microfrontends. But independent does not mean uncoordinated. When you change a shared interface — a data contract, a shared event, a URL parameter — you need to deploy in the right order and maintain backward compatibility. This is coordination under a different name.

The small-team trap

The most common microfrontend mistake is adopting them too early, on a team that is too small.

Microfrontends are designed to reduce coordination overhead between teams. If you have one team, there is no coordination overhead to reduce. You get all the complexity with none of the benefit.

A team of five engineers shipping a single product does not need:

• Three deployment pipelines
• Module Federation version management
• Cross-application integration testing
• A platform engineer dedicated to maintaining the shell

They need a well-structured React application with clear module boundaries. That is achievable with good folder structure and coding discipline.

Readiness signals

Before adopting microfrontends, you should be able to say yes to most of these:

• We have three or more frontend teams with genuinely separate codebases.
• Our domain boundaries are so clear that separate teams almost never touch each other's code.
• We have a platform or infrastructure team that can own and maintain the shell.
• We have already felt the concrete pain of a monolithic frontend: blocked deployments, merge conflict storms, impossibly slow CI.
• We have the operational maturity to run and monitor multiple separate deployables.

If you cannot say yes to most of these, you are optimising for a problem you do not yet have.

The tradeoff checklist

Use this before any architectural decision to adopt microfrontends:

What specifically hurts today? Write it down in concrete terms. "Deployments are blocked" is concrete. "The codebase feels large" is not.

Could a better monolith solve it? Strict module boundaries, feature-flag-gated releases, and a well-structured codebase can often address the pain without the operational overhead of MFEs.

Do we have the team to support it? Module Federation requires someone who understands webpack internals, shared dependency management, and runtime composition. If no one on the team has done this before, the learning curve is steep.

What is our fallback if it fails? Migrating back from microfrontends to a monolith is painful. Make sure the decision is reversible or that you are confident enough to live with it.

Readiness checker

When a modular monolith is the right answer

A modular monolith — a single deployable with strong internal module boundaries — delivers most of the developer experience benefits of a monorepo without the operational complexity of microfrontends.

Each domain has its own folder, its own types, and its own test suite. Imports between domains are explicit and reviewable. A lint rule can enforce that no domain imports from another domain's internals.

This is the right starting point for the vast majority of frontend teams. Reach for microfrontends when you have definitively outgrown it — not before.