A front-end lead proposes micro-frontends so four teams can deploy independently. The application is a single React SPA. What is your assessment?

Test the premise first

The stated goal is independent deployment. Ask what currently prevents it, because the answer is frequently not the architecture.

If the blocker is a shared release train, a manual QA gate or a fortnightly window, micro-frontends will not remove it — those are process constraints and they will apply to the fragments too. If the blocker is that a change by any team requires rebuilding and retesting the whole application, that is genuine and it is what this addresses.

Measure it: how often does one team's release actually wait on another's, and for how long? If the answer is rarely, the architecture is solving a problem the organisation does not have.

If the premise holds, be explicit about the cost

Composition must be at runtime. Build-time composition means a change to any fragment requires rebuilding and redeploying the shell, which is exactly the coordination being removed. Server-side inclusion, edge assembly or remote module loading — each with a timeout and a fallback, so a failing fragment degrades one region rather than blanking the page.

The shared runtime is the real cost and it is consistently underestimated. Fragments share one DOM, one set of global styles, one router, one authentication state and often one framework instance. Two fragments on different major versions either both ship the framework — doubling the bundle for every user — or one is constrained by the other's upgrade schedule, which is the coupling that was supposed to have been removed.

Performance regresses by default. More requests, duplicated dependencies, and composition work in the critical path. That is recoverable with effort and it is not free.

Testing gets harder. Integration must run against deployed remotes, since the local copy is exactly what runtime composition means you are not using.

The alternative worth putting on the table

A modular monolith: strict module boundaries within one build, enforced by lint rules and ownership, with a single deployment. It gives most of the code-organisation benefit, none of the runtime cost, and it is reversible.

The recommendation

Micro-frontends earn their cost when teams genuinely cannot release together — usually because of organisational separation rather than technical coupling. For four teams in one organisation on one product, that is a high bar. I would fix the release process first, measure again, and treat the architecture as the answer only if the coordination cost survives that.