Micro-frontends are not automatically good or bad. They are a trade-off.
They can help teams own separate parts of a product, deploy independently, and reduce coordination bottlenecks. But they can also introduce duplicated dependencies, inconsistent user experience, and more operational complexity if the architecture is not intentional.
The most important question is not "Can we split this application?" The better question is "Where does independent ownership actually help the product?"
Boundaries matter
A good micro-frontend boundary should usually align with product ownership, user journeys, and release independence. If the split only follows technical folders, it can create more friction than value.
Some lessons I keep in mind:
- Shared design systems matter more, not less.
- Performance budgets should be visible across teams.
- Platform contracts should be boring, stable, and documented.
- Local developer experience should not become an afterthought.
- A micro-frontend should still feel like part of one product.
The real work
The architecture is only one part. The real work is making sure teams can build confidently without turning the user experience into a collection of disconnected pieces.