Are micro frontends worth it for a product that will eventually split off?

November 13, 2026 4 answers
Asked by socks_before_statistics

Our product currently runs inside another team's platform, but needs its own frontend customization connected to a product-specific API. The longer-term plan is to make it a standalone platform.

Would micro frontends help keep the domains separate and make that transition easier, or would a simpler setup be better? I'm also looking at Single-SPA and Module Federation, but open to alternatives.

Answers

tape.dispenser.dilemma

For a temporary customization, I'd start with a feature module inside the existing app rather than introduce a whole micro frontend architecture. Keep the product-specific UI and API code together, with clear boundaries around what it imports from the host.

A monorepo can help organize that split, and lazy loading may be useful if the feature is substantial. Neither guarantees an easy extraction, but you can work toward that by keeping dependencies on the host explicit.

Reply to this answer
shift+click+shrug

Does the feature actually need to live inside the other product's interface? If not, a separate app under its own subdomain is a much simpler boundary. Share a design system library where it makes sense, but let each app deploy independently.

who-left-the-flap-open:

That works best if users can move between the products without needing the customization embedded in the existing page.

Reply to this answer
ack9.window

I'd hold off on choosing between Single-SPA and Module Federation until the integration requirement is clearer. Both point toward composing separate frontend pieces, but that is a different problem from simply keeping one product's code out of another team's domain.

If independent deployment of an embedded feature is a real requirement, investigate those tools. If the main goal is a future split, a shared library or a well-isolated module could be enough for now.

Reply to this answer
2f+checksum

Separate apps don't necessarily need separate repositories or identical stacks. A monorepo can hold multiple products alongside shared UI libraries and schemas, while each app remains its own application. That gives teams room to choose tools that fit what they maintain without requiring runtime frontend composition.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions