Do you actually need micro frontends?

Most articles about micro frontends assume you have already decided. This one does not, because the honest answer for a lot of teams is no — and the cost of finding that out after the migration is high enough to be worth ten minutes now.

What problem do micro frontends actually solve?

Coordination. Not performance, not bundle size, not code quality — those usually get slightly worse. What improves is the ability of several teams to release without asking each other's permission.

That is the whole trade. You accept a distributed system in the browser, with everything that implies, in exchange for teams that no longer queue behind one another. If nobody is queueing, you are paying the price and collecting nothing.

What says yes?

• Several teams touch the same frontend, and releases are a negotiation. A shared release train, a merge queue with a name people say bitterly, a Slack channel for coordinating deploys.
• One team is blocked by another's readiness. The checkout team is done on Tuesday and ships on Thursday, because that is when the shell goes out.
• Parts of the product have genuinely different rhythms. A marketing surface that changes daily and a trading view that changes quarterly do not belong in the same release cadence.
• You are replacing a legacy frontend incrementally. Strangling an old application route by route is one of the cleanest reasons to adopt them, and one of the few where the technical argument leads.

What says no?

• One team. Module boundaries in one codebase give you most of the isolation and none of the runtime cost. If the answer is a better folder structure, use a better folder structure.
• Build times are the complaint. Micro frontends do not fix slow builds; they multiply the number of them. Caching, incremental builds and a faster bundler are cheaper and more direct.
• The frontend is small. Below a certain size the orchestration overhead is larger than the thing being orchestrated.
• Nobody owns anything yet. Micro frontends need clear ownership per surface. Introduced into a team without it, they distribute the confusion rather than the work.

What does it cost if you do it anyway?

More pipelines, more artefacts, more places to look when something breaks. A shared dependency story that has to be decided rather than assumed. Integration testing that now spans deployables. And a new class of failure — the runtime composition failure — that a single bundle simply cannot have.

Most of these are manageable. The one that surprises teams is versioning: once micro frontends deploy independently, knowing which version of what is live in which environment stops being obvious, and stays not-obvious until something is built to answer it.

What should you try first?

1. Fix ownership. Name an owner per surface, in one codebase. Much of the pain is ownership pain wearing an architecture costume.
2. Enforce module boundaries. Lint rules or project references make crossing a boundary a deliberate act, in one repository, with none of the runtime cost.
3. Speed up the build. If the pain is the wait, address the wait.
4. Split one surface. If after all that the coordination pain is real, extract exactly one micro frontend — ideally the one with the most independent release rhythm — and live with it for a quarter before extracting a second.

And if the answer is yes?

Then the thing to get right early is not the loading mechanism. Module Federation, web components and import maps all work. What decides whether this is pleasant in a year is whether you can answer, at any moment, which version of each micro frontend each environment is serving — and change that answer without rebuilding everything.

Get that right and the rest is ordinary engineering: rollback becomes a write rather than a deploy, and releasing carefully becomes a choice rather than a project.

But start with the question. Micro frontends are an answer to team scale, and team scale is not a problem you should give yourself in advance.