Large organizations rarely have one frontend team — they have several, each responsible for a different part of the product, often shipping on different schedules. When all of those teams share a single monolithic frontend codebase, releases slow down, ownership blurs, and a small change in one area can quietly break another.
Micro-frontends address this by splitting a large web application into independently deployable pieces, each owned end-to-end by one team, then composed together at runtime or build time into a single experience for the user.
The appeal isn't purely technical. Micro-frontends map an architecture onto an organization's actual team structure, so that release cadence, code ownership, and on-call responsibility line up with how the business is organized. A checkout team can ship independently of a search team, even though both render on the same page.
There are a few common ways to stitch micro-frontends together: build-time integration via package publishing, run-time integration via iframes or Web Components, and edge-side or server-side composition. Each trades off isolation against shared-dependency overhead and initial load performance — the right choice depends on how much your teams need to move independently versus how tightly the UI needs to feel unified.
The most common failure mode isn't technical either — it's over-fragmentation. Teams split a frontend into micro-frontends before they have the organizational boundaries to justify it, and end up paying the coordination cost of a distributed system without gaining any real team autonomy. We generally recommend starting with a modular monolith and only splitting boundaries once a team's release cadence is genuinely blocked by another team's code.
Micro-frontends are a strong fit for large, multi-team enterprise products with clear domain boundaries — think a retailer's search, cart and account sections, each owned by a different squad. For smaller products and single teams, the added infrastructure rarely pays for itself. As with most architecture decisions, the right call depends on your team's shape more than your codebase's size.