A company adopts micro-frontends across many teams. Two years later the product is slower, visually inconsistent and harder to change. What went wrong?
Show the full answer Hide the answer
The performance failure
Each micro-frontend ships its own framework copy and its own dependencies. A user loading a page with five of them downloads five runtimes. Shared dependency configuration exists to prevent this and requires version alignment across teams — which is precisely the coordination micro-frontends were adopted to avoid.
The result is the common one: independence in deployment, purchased with a bundle size that grows with team count.
The consistency failure
Independent teams make independent visual and interaction decisions. Without a design system that is genuinely mandatory and genuinely complete, the product becomes visibly assembled from parts. Users experience this as low quality even when every individual part is good.
The changeability failure — the one that surprises people
Cross-cutting changes now require coordination across every team, which is worse than in a monolith where a single change reaches everything. Micro-frontends optimise for independent change within a boundary and make change across boundaries considerably harder.
If most of the product's valuable changes are cross-cutting — a navigation redesign, an authentication change, a design refresh — the architecture is working against the actual change pattern.
What should have preceded the decision
- A shared design system, adopted, before splitting. Retrofitting consistency across independent teams is far harder than starting with it.
- An honest look at the change pattern. Micro-frontends pay off when teams genuinely own separable product areas with few cross-cutting changes.
- A performance budget enforced across the composed page, not per micro-frontend, since no individual team owns the total.
- A test of whether the constraint was actually deployment coupling. Frequently the real problem is a slow build or a fragile test suite, and those are cheaper to fix directly.