Micro-frontends · Basics

What are micro-frontends? A plain guide for decision makers

Micro-frontends split one large web application into parts that separate teams can build and release on their own. This guide explains the idea, the benefits and the bill, without code.

By Carlos Cifuentes · Frontend architect · Updated 2026-10-02

The short definition

A micro-frontend architecture splits one web application into several smaller frontend applications. Each one covers a business area, such as billing, catalog or customer support. Each one is owned by one team, built in its own pipeline and deployed on its own schedule.

A thin application called the host (or shell) puts them together in the browser. The user still sees one product, with one login and one menu.

The idea is the one behind microservices, applied to the user interface. Many large companies split their backend years ago. The frontend often stayed as a single large application that every team has to change.

The problem they solve

A single large frontend works well while one team owns it. It starts to hurt when several teams share it:

One release train. Every team ships on the same day, from the same build. One team's unfinished work delays everyone.
Shared risk. A bug in the reports screen can block a release that contains an urgent payments fix.
Slow builds and tests. The whole application is compiled and tested for every change, even a one-line change.
Unclear ownership. Code that everyone can change tends to belong to nobody.
All-or-nothing upgrades. Moving to a new framework version requires every team to stop at the same time.

Micro-frontends give each team a part of the product that it can change and release without asking the others.

What changes for teams

Ownership by business area. A team owns a vertical slice: the screens, the frontend code, the pipeline and the production behavior of its area.
Fewer release meetings. There is no shared release calendar for the frontend. Coordination moves to a small set of written agreements: how navigation works, how login is shared, which design system version is in use.
A platform team appears. Someone has to own the host, the shared libraries and the delivery tooling. It is a small, permanent role; the exact size depends on the company.

How team structure and architecture shape each other is covered in Team ownership and Conway's law.

What changes for releases

Each micro-frontend is built and deployed separately. The host finds out at runtime which version of each part to load. This has three practical effects:

A team can release several times a day without a company-wide regression cycle.
A faulty release is rolled back for one area only. The rest of the product is unaffected.
A framework upgrade or a legacy migration can go area by area. This is why micro-frontends often appear in modernization projects. See Rewrite, hybrid or micro-frontends: how to choose.

What they cost

The benefits are organizational. The costs are technical, and they are permanent.

Cost	What it means in practice
Platform work	A host, a way to load parts at runtime, shared pipelines and monitoring
Consistency	A shared design system, so five teams still produce one product
Contracts	Written rules for routing, login, events and shared libraries
Performance	Several bundles instead of one, and duplicated code if sharing is not managed
Testing	Each part is tested alone, and the composed product needs its own tests
Local development	Developers need a way to run their part against the rest

For a single team, these costs come without the benefits. A well-structured single application with clear module boundaries is cheaper to build and cheaper to run.

A more detailed breakdown, including the people cost, is in The real cost of micro-frontends.

Common misunderstandings

"They make the app faster." They usually make loading performance harder to manage, because the browser downloads several independently built parts.
"They fix messy code." A badly structured area stays badly structured after it is split out.
"Every team can pick its own framework." Mixing frameworks is technically possible. Each additional one adds weight to the page and skills the company has to maintain.
"It is a project with an end date." The platform needs an owner for as long as it exists.

Questions a decision maker should ask

How many teams change the frontend today, and how often do they block each other's releases?
Can we draw the business areas on a whiteboard so that most screens fall clearly into one area?
Who will own the host and the shared libraries, and is that role funded?
Do we have a design system, or will we need to build one?
What is the smallest first step that would prove the approach on one area?

If the answer to the first question is "one team" or "rarely", you can stop here. If several teams wait on each other every sprint, continue with When micro-frontends are worth it.

Planning a migration or a micro-frontend platform?

In a 20-minute call you describe your situation and I tell you how I'd approach it. If it isn't worth doing yet, I'll say so.

Message me on LinkedIn