Microfrontends are an organisational solution — they only pay off when the team and product are large enough to justify the overhead.
Do NOT use microfrontends when:
- Small team (<10 engineers) — one team can't benefit from independent deployability. You just add complexity.
- Tight UX coupling — if features constantly share components and state, you're fighting the architecture every day.
- Early-stage product — domain boundaries are unclear. Split too early and you'll get the seams wrong and need to undo them.
- Performance is critical — multiple independent bundles + runtime module loading adds latency that a monolith doesn't have.
- No strong ownership model — microfrontends require each team to own and operate their slice end-to-end. Without that culture, you just get a distributed monolith.
💡 Rule of thumb: if you need microfrontends, you'll know — because merging PRs across teams is blocking your release cadence. Start with a well-structured monorepo first.