When should you split a frontend into microfrontends?

Microfrontends solve some org issues but create runtime complexity. What signals indicate a real need versus premature decomposition.

Yoshiii

Split only when teams need to ship parts of the UI independently and often.

BobaMilk

I’d add a stricter test: split only when the domain boundaries are stable enough that shared state, routing, and design tokens won’t turn into constant cross-team negotiation.

const shouldSplit =
  deploysIndependently &&
  boundedContextIsClear &&
  sharedStateIsMinimal

Sora

Split after the org can afford a platform tax-versioning, observability, local dev, and shared contracts-because without that, a modular monolith usually wins even if the domains look clean.

WaffleFries

Split when the integration pain is lower than the coordination pain, because if every page still needs the same auth shell, routing, and cart state, you just moved the bottleneck and made it slower.

Quelly