An organisation is considering micro-frontends so teams can deploy independently. What does this actually require, and when is it the wrong answer?

The problem it addresses

Many teams contributing to one frontend application means a shared release train: every change waits for every other, one team's failing test blocks everyone, and the deployment coordination cost grows with team count.

Micro-frontends decompose the application so each team owns, builds and deploys a portion independently.

What it actually requires

• Genuinely independent domains within the UI. If every page combines fragments from four teams, the independence is fictional and the coordination cost has moved rather than reduced.
• A composition mechanism: build-time integration, server-side composition, or runtime module federation. Each has substantially different trade-offs, and runtime composition — the most flexible — is also the one that risks the most at runtime.
• A shared design system with versioned components, or the product looks like several products. This is the largest ongoing cost and it is consistently underestimated.
• Contracts between fragments, since a fragment is now a published interface.
• Shared dependency strategy. Without it, each fragment ships its own copy of the framework and the bundle is multiplied by the team count — which is the failure that makes users pay for the organisation's structure.
• Cross-fragment state and navigation handled deliberately, since they are the parts that couple teams back together.
• Observability spanning fragments, so a broken page can be attributed.

When it is the wrong answer

• A small number of teams. Below roughly five or six, the coordination cost is lower than the micro-frontend overhead, and a monolithic frontend with clear module boundaries and enforced dependency rules achieves most of the benefit.
• A highly-integrated interface, where fragments must communicate constantly. The coupling is inherent in the product, and decomposing the code does not decompose it.
• When the actual bottleneck is something else — a slow test suite, a manual release process, environment scarcity, or unclear ownership. Diagnose before restructuring: the same symptom has several causes and this is the most expensive response available.
• When performance is the primary requirement. Micro-frontends cost bytes, and the user pays for the organisational structure.

The alternative that usually works

A modular monolith for the frontend: one application, one build, one deployment, with strict module boundaries enforced at build time and clear team ownership per module.

This gives ownership, isolation and independent development without the runtime composition, duplicated dependencies and design fragmentation — and it defers the decision until there is evidence the deployment coupling is genuinely the constraint.

The signal that justifies the move is measured: the number of teams that must coordinate for a typical release, and the delay that coordination imposes. "Teams want independence" without that measurement is a preference, and micro-frontends are an expensive way to satisfy a preference.