Microfrontends: When They Help and When They Don’t

What is a microfrontend?

The easiest way to explain a microfrontend is this: one part of a product is owned and released by one team.

It is not about making every button or card a separate application. It is about giving a team a clear business area, such as Catalog or Checkout, that it can change without waiting for every other frontend team.

This is also the main idea behind micro-frontends.org: split the product by features owned by independent teams.

If five repositories still have to be deployed together, they are not really independent. You probably have a distributed monolith, which is usually harder to work with than one well-organized application.

When they can help

I would start with a modular monolith in most projects. One repository and one deployment are easier to understand, test, and refactor.

Microfrontends start to make sense when several long-lived teams own different parts of a large product and often block each other during releases.

Some useful signs are:

• Each team owns a clear business area

• Teams need to release at different times

• One frontend build or test suite has become a delivery bottleneck

• Old and new applications need to run together during a gradual migration

A large number of components is not enough reason by itself. Better folders and clearer modules may solve the problem with much less complexity.

When they do not help

Using microfrontends because a big company uses them is a weak reason. Big companies have team and release problems that smaller products may never have.

Letting every team choose a different framework can also sound exciting, but users still expect one consistent product. You may end up rebuilding the same design, accessibility, logging, and performance work several times.

They will not clean up messy code either. Unclear ownership stays unclear after the code is split—it just becomes harder to trace across applications.

My simple rule is: do not create a distributed system to fix a folder-structure problem.

Split by business area

Imagine an online shop. Splitting it into Header, Form, and Button applications would force teams to coordinate on almost every feature.

A better split is Catalog and Checkout. Catalog owns search and product pages. Checkout owns the cart, delivery, payment, and confirmation flow. These boundaries match things the business and the customer already understand.

A small shell can connect them. It may own routing, navigation, login state, shared design tokens, and common error handling. The business rules should stay inside Catalog or Checkout.

catalog/
  owns: search, product list, product details
  routes: /products/* and /search

checkout/
  owns: cart, delivery, payment, confirmation
  routes: /cart and /checkout/*

shell/
  owns: navigation, login state, shared styles, routing

Keep the connections small

The applications are separate, but they still need to feel like one product. That means they need a few clear agreements.

Routes should have one owner. All apps should understand the same small session format. Shared design tokens should keep colors and spacing consistent. Important data such as the cart should live behind an API instead of inside one app's memory.

Be careful with large shared packages. If every app must update the same package at the same time, independent releases disappear.

The cost is real

The benefit is clear ownership and smaller, independent releases. That can be valuable when several teams work on a large product.

The cost is more deployments, more monitoring, duplicated dependencies, harder local development, and more testing between applications. A page may also feel inconsistent if teams stop sharing basic design and accessibility rules.

Microfrontends do not automatically isolate failures. If the shell cannot work when one application is down, that application can still break the whole experience.

This is why I would choose this architecture only when team independence is worth the extra operational work.

Start small

Do not rewrite the whole frontend. Pick one domain with a clear route, move it, and see what happens in production.

Measure whether releases became faster, whether teams coordinate less, and whether performance and reliability stayed healthy. If the first extraction does not help, stop there.

1. Start with a modular monolith.
2. Pick one domain with clear routes and one owning team.
3. Move traffic to the new app without changing the public URL.
4. Extract another domain only if the first move helped.

Final thoughts

Microfrontends are useful when software boundaries match real team boundaries. They are not an automatic upgrade from a monolith.

Start with good modules. Notice where teams repeatedly block each other. Split one business area only when independent ownership and deployment are worth the extra complexity.

In Part 2, I show a simple Next.js example with separate Catalog and Checkout applications.