Micro-Frontends Are an Org Chart Decision, Not a Technical One

I've sat through more than one micro-frontends pitch, and they all open the same way: a slide about independent deployments, a slide about teams not blocking each other, maybe a slide about being able to use a different framework per app "if we ever need to." It's a technical pitch, delivered with technical slides, aimed at a technical audience.

Here's the thing I think gets buried under all of that: almost none of it is actually a technical problem. It's an organizational one wearing a technical costume, and the pitch works better when it's honest about that from the start.

You don't split a frontend into micro-frontends because the code is too big. You split it because the teams touching that code can no longer coordinate at the speed the org needs.

That's not a knock on micro-frontends. It's a claim about what actually justifies them — and it means the right first question isn't "is our bundle too big" or "do we need framework flexibility." It's: does our org chart already have the shape that micro-frontends are supposed to reflect?

What the technical benefits actually cost

Every micro-frontend benefit on the slide has a real, un-glamorous cost that doesn't make it into the pitch.

Independent deploys sound great until you notice that a single-repo monolith with a decent CI pipeline can also deploy independently deployable features behind flags, without ever splitting the app. What micro-frontends actually buy you over that is independent deploys without needing anyone else's review or coordination — which is a genuine win, but only if the reason you needed that isolation was that coordinating with the other team was the actual bottleneck, not the deploy pipeline itself.

Framework isolation — "team B can use Vue while team A uses React" — sounds like flexibility and is usually a cost nobody priced in. You now ship two frameworks' runtimes to every user, you've doubled your hiring and knowledge-sharing surface, and the actual reason teams reach for this is almost never "Vue is better for this specific problem." It's normally "team B inherited a Vue app during an acquisition and nobody wants to rewrite it." That's a real reason. It's an organizational one, not an argument that framework diversity is good architecture.

Smaller bundles per team is the one that sounds most like a real technical win, and it's the one I'd push back on hardest. Splitting an app into micro-frontends doesn't shrink the total code the user downloads — it usually grows it, because now you're shipping duplicated dependencies (React itself, your design system, your date library) once per micro-frontend unless you invest heavily in shared-dependency tooling, which is its own significant ongoing cost. If bundle size is your actual problem, code-splitting inside a single app solves it directly, cheaper, and without any of what follows in this article.

The cost nobody puts on the slide

Once you've actually split the frontend, a list of problems shows up that no diagram warned you about.

Cross-app state gets hard in a way that's easy to underestimate. A shopping cart, a logged-in user, a feature flag — anything that needs to be consistent across micro-frontends now needs a real synchronization mechanism, and "we'll just use custom events" is the sentence every team says right before building an ad hoc, under-tested message bus by accident.

Design system drift becomes a constant, low-grade tax. Each micro-frontend can update its dependencies, including your shared UI kit, on its own schedule — which is the whole point — and that means you will, eventually, ship a page where the button in the header and the button in the body are visually two versions apart, because two teams updated on two different weeks.

And orchestration — routing between micro-frontends, sharing auth state, handling the moment one micro-frontend fails to load while the rest of the page is fine — is genuinely hard engineering that a single-app architecture simply doesn't need to solve, because there's only one app.

None of these costs are disqualifying. They're the price of the thing micro-frontends are actually good at: letting teams ship independently without waiting on each other. The mistake is paying that price for a benefit you didn't need.

The question that actually decides it

So here's the test I'd apply before anyone reaches for micro-frontends: can two teams currently ship features to production without one blocking the other, in the architecture you already have?

If the honest answer is yes — one repo, decent ownership boundaries, feature flags, a CI pipeline that doesn't make Team A wait on Team B's review — then you don't have the problem micro-frontends solve. You have a problem that looks similar (big app, multiple teams) but isn't actually causing the pain micro-frontends are priced to fix, and adopting them will hand you the costs above in exchange for nothing.

If the honest answer is no — teams are routinely blocked on each other's release windows, a shared repo's CI queue has become a real bottleneck, or (the case I'd take most seriously) you've inherited genuinely separate applications from an acquisition or a long history of independent teams and merging them isn't realistic — that's the org chart telling you the org is already split. Micro-frontends, in that case, aren't creating the split. They're the architecture that finally matches a split that already exists in how the company works.

That's Conway's Law, and I don't think it's a fun aside here — it's the actual decision criterion. Your system's structure is going to mirror your communication structure whether you plan for it or not. Micro-frontends are what you get when you deliberately let that happen instead of fighting it with an org chart your codebase doesn't reflect.

What I'd actually check first

Before signing off on a micro-frontends architecture, I'd want to see the org chart, not the bundle analyzer. How many teams actually own frontend code that needs to ship independently? Is the current blocker genuinely architectural, or is it a CI pipeline that could be fixed for a fraction of the cost of a rewrite? And if the teams merged into one tomorrow, would the case for micro-frontends survive that?

If it wouldn't — if the whole justification evaporates the moment you imagine one team owning all of it — then you weren't looking at an architecture problem. You were looking at a coordination problem, and there's usually a cheaper fix for that than teaching your frontend to run as five separate applications that now have to talk to each other.