Micro-frontends get sold as the mature choice, the "scaling" choice. Break your frontend into independently deployable pieces, the pitch goes, and your organization scales forever. Here is my version, after running a fleet of production services as effectively a one-person shop: micro-frontends are a solution to an organizational problem, and adopting them without the organization is how you inherit all of the cost and none of the benefit.

Who actually has this problem

Micro-frontends exist for companies with hundreds of frontend developers on specialized teams, a Checkout Team and a Search Team that must ship independently without stepping on each other. The technology buys organizational isolation: separate repos, separate deploys, separate on-call. If you are a solo developer, or a team of five, read that list again. You already have the isolation. You have one repo, one deploy, one on-call: you. Splitting the frontend now buys you a distributed system's failure modes inside a codebase that one person could have held in their head.

What it costs

• Tooling tax. Module federation or its equivalents, specialized routing, version negotiation between fragments, permanent infrastructure work that produces zero user-visible value.
• Design-system drift. Keeping one UI consistent is hard with one team. With independently deployed fragments, it becomes archaeology.
• Bundle bloat. If federation isn't tuned perfectly, your users download React three times. Your performance problem arrives with the architecture that was supposed to solve your scale problem.

What to do instead

For small teams the answer is almost boring: a monolith, kept healthy. Modern build tooling makes a single codebase fast to build and easy to refactor, and a monolith is the only architecture where "it's all in one place" is still true when you're debugging at 1am. And if you genuinely need isolation, separate concerns, independent release cadence, bounded blast radius, there is a much older trick: build separate applications and put a reverse proxy in front of them. I run a small fleet of production sites this way. nginx routes by subdomain, each app is its own codebase and its own systemd unit, and a bad deploy in one takes down exactly one thing. That is all the independence micro-frontends sell, with tooling from 2005 instead of a federation layer nobody can debug.

A quieter take

Wait until your org chart forces your hand, until you actually have two teams that genuinely cannot coordinate, and then adopt micro-frontends for that specific seam and nothing more. Until then, every hour spent on federation is an hour not spent on the product. Scale problems are good problems, and almost none of us have them yet. Keep it a monolith until the pain is real, and when the pain is real, consider whether a proxy and two apps is the honest fix.