Micro-frontends split a single web application into independently deployable pieces, each owned and shipped by a different team, composed together at runtime into what the user experiences as one product. The pitch is compelling on paper — teams ship independently, on their own schedules, without coordinating a single monolithic frontend release — and it solves a genuinely real problem for organisations with several substantial teams working on one large product.
The problem it doesn't solve, and shouldn't be adopted to solve, is a technical one. A single team's frontend that feels messy or hard to maintain is not fixed by splitting it into micro-frontends — that's an architecture problem within one codebase, and micro-frontends address organisational boundaries between separate teams, not code quality within one. Adopting the pattern for a codebase owned by a single team just adds runtime composition complexity with no corresponding organisational benefit.
The genuine cost, which the pitch tends to understate, is consistency. Multiple independently-deployed frontend pieces sharing a page need a shared design system, shared versions of common dependencies, and careful coordination on anything cross-cutting — authentication state, routing, shared components — or the user experiences a product that visibly feels stitched together from different pieces built at different times with different assumptions. This is exactly the coordination overhead the pattern was meant to remove, reappearing at the design and shared-infrastructure layer instead of the deployment layer.
The honest test before adopting: do you have multiple genuinely independent teams, each with a real reason to deploy on their own schedule, working on distinct parts of one large product? If yes, micro-frontends solve a real coordination problem worth the added complexity. If the actual situation is one team wanting a cleaner architecture, the fix is better modularisation within a single codebase, which delivers most of the maintainability benefit without any of the runtime composition cost.
