Micro Frontends for Brand Sites: Multi-Team Collaboration, Stack Isolation, and Independent Deploys
1. What Micro Frontends Actually Solve
Micro frontends split one frontend app into multiple sub-apps by business domain. Each sub-app is built and deployed by its own team, and a shell app assembles them all into the same page. Think of it as microservices for the frontend: the backend breaks a big system into services that deploy independently, and the frontend can do the same.
It solves three specific pain points. First, multiple teams editing the same codebase run into merge conflicts more and more often. Second, team A wants to upgrade to React 19 while team B is still on React 17, and each holds the other back. Third, a small change requires a full build and a site-wide release, with regression testing across the whole site and rising risk. All three come from organizational scale, not from a lack of technical skill.
The counterintuitive part: the payoff from micro frontends scales with team size. The smaller the team, the more micro frontends cost you. A 3-person frontend team that splits into micro frontends adds three layers of complexity, a shell app, route coordination, and cross-app communication, when they never had merge conflicts to begin with. For how to choose a WordPress stack, see WordPress Tech Stack Selection.
| Metrics | Not a fit for micro frontends | Micro frontends worth considering | Micro frontends required |
|---|---|---|---|
| Frontend teams | 1 | 2 | 3 or more |
| Lines of code | Under 100,000 | 100,000 to 500,000 | Over 500,000 |
| Release cadence | Once a week, together | Some teams ship monthly | Mix of weekly and daily |
| Stack conflicts | Fully unified | A few conflicts | Multiple frameworks side by side |
| Product type | Marketing site only | Marketing site plus a simple admin | Marketing site plus complex SaaS plus admin |
| Deploy complexity | One repo, one build | One repo, multiple builds | Multiple repos, multiple builds |
2. Three Common Approaches and How to Choose
The first is Module Federation, a built-in webpack 5 feature. Each sub-app declares which modules it exposes at build time, and the host app loads them at runtime. The upside is tight integration; the downside is that webpack versions must match and debugging gets complicated. Best for React/Next.js teams already on webpack.
The second is import-map + SystemJS. Sub-app URLs are declared in a JSON file at runtime, and the host app loads them on demand. The upside is complete stack isolation, so sub-apps can be React, Vue, Svelte, whatever you like. The downside is that you handle cross-app style isolation and routing coordination yourself.
The third is a monorepo with multiple apps (Monorepo + separate builds), managed with Nx or Turborepo, where each package builds and deploys independently. The upside is easy code sharing; the downside is that the bigger the repo, the slower the build, so it does not suit very large teams. For how to structure internal linking, see internal linking system.
| Solution | Stack isolation | Learning curve | Build complexity | Best for |
|---|---|---|---|---|
| Module Federation (Webpack 5) | Medium (same host framework) | 2 to 3 weeks | Medium | React teams, 20 to 50 people |
| import-map + SystemJS | High (frameworks can mix) | 3-4 weeks | High | Multiple frameworks, 50+ people |
| Monorepo + multiple apps | Low (shared dependencies) | 1 to 2 weeks | Low | Multiple teams on one framework, 10 to 30 people |
| iframe micro-frontend | Extremely high | Extremely low | Low | Temporarily integrating a third-party page |
3. When does a B2B site really need micro-frontends?
A purely marketing B2B site, with only a homepage, product pages, a blog, About Us and Contact Us, does not need micro-frontends. Sites like this usually run under 50,000 lines of code, which one person can maintain without much trouble, so splitting into micro-frontends just creates work for yourself.
What really needs them is a site that combines a marketing site, a customer portal and a dealer admin panel. Take an industrial platform going global: the marketing content is owned by the marketing team (Next.js, SEO first), the customer ordering and lookup system by the product team (React, interaction first), and the dealer admin panel by the ops team (Vue, tooling first). The three teams release on different schedules, use different stacks, and each owns over 100,000 lines of code. In that case, micro-frontends stitch the three sub-apps into different routes under one domain, and each team deploys independently without affecting the others. For how site monitoring works across multiple apps, see Site monitoring and alerts.
A real-world example: a SaaS company going global had a marketing site on Next.js and a user dashboard on React + Redux, originally deployed on different subdomains. They found that after logging in, users jumping from the marketing site to the dashboard crossed domains and the experience broke. They used Module Federation to merge both apps into one host app, with a unified nav bar, shared login state, and independent deployment. Changes to the marketing site do not affect the dashboard, and changes to the dashboard do not affect the marketing site. Release frequency went from once a week to twice a day.
| Challenge | How a monolith does it | How micro-frontends do it | Benefit |
|---|---|---|---|
| Release frequency | Full regression, once a week | Ship sub-apps independently, multiple times a day | Release 5 to 10 times faster |
| Tech stack upgrades | Upgrade everything at once, high risk | Upgrade sub-apps one at a time | Upgrade cycles drop from quarters to weeks |
| Team collaboration | Frequent merge conflicts in one repo | Separate repos, agreed interfaces | 80% fewer merge conflicts |
| Blast radius of failures | One bug takes down the whole site | A sub-app crash only affects its own area | Smaller failure blast radius |
| Onboarding new hires | Must understand the entire site | Only need to know their own sub-app | Onboarding drops from 4 weeks to 1 |
Four: the three biggest pitfalls of micro frontends
Pitfall one: style pollution. Two sub-apps both use Bootstrap, and when loaded on the same page, the styles fall apart. The fix is CSS namespacing (prefix each sub-app) or Shadow DOM isolation. It’s not a technical challenge, but you must set the rules early in the project, or painful rewrites follow.
Pitfall two: cross-app communication. A user fills out a form on the marketing site and wants to bring that data to the dashboard in the user center. If the two sub-apps are fully independent, communication relies on URL parameters or localStorage, which gets messy as data grows. The fix is a global state manager (like zustand) in the shell app, with sub-apps reading and writing through agreed interfaces. Don’t let sub-apps call each other directly.
Pitfall three: performance fragmentation. Each sub-app loads its own copy of React, so users download three copies of React and total JS size jumps from 500KB to 1.2MB. The fix is to put shared dependencies like React and Vue in the shell app, with sub-apps referencing them through a shared scope instead of bundling duplicates. For managing third-party scripts, see Managing third-party scripts.
| Pitfall | Symptoms | Solution | Preventive action |
|---|---|---|---|
| Style pollution | Sub-app A’s buttons take on sub-app B’s styles | CSS prefixes or Shadow DOM | Set style rules early in the project |
| Messy shared state | Data lost between sub-apps | Centralized state management in the shell app | Agree on shared interfaces and data structures |
| Duplicate JS bundles | Each sub-app bundles its own framework | Hoist shared dependencies to the shell app | Analyze duplicate bundles at build time |
| Out-of-sync routing | Sub-app returns 404 after refresh | Centralized routing in the shell app | Configure routing rules in one place |
| Hard to debug | Errors with no clue which sub-app they came from | Unified error monitoring + sub-app tags | Sentry with sub-app tags |
FAQ
How is a micro frontend different from an iframe? Can’t I just use an iframe?
Should a 5-person frontend team split an 80k-line codebase into micro-frontends?
Do micro-frontends slow down first paint?
Can a WordPress site do micro-frontends?
How do you set up deployment for micro-frontends?
Do micro-frontends affect SEO?
Final thoughts
Micro-frontends are a scale-driven architectural decision. When your team is small, they’re a burden; when your team is large, they’re the cure. Whether to split shouldn’t be decided by whatever’s trending in tech, but by the pain you’re actually feeling right now: Are you resolving merge conflicts every week? Does changing a single line of copy still trigger a full regression test? Are two teams blocking each other because their tech stacks don’t match? If you answer “yes” to two of those three, then consider splitting.
Start by splitting off your single biggest pain point: take the sub-app you ship most often (usually the campaign landing page) and make it independent, leaving everything else alone for now. Run it for three months and check the payoff: if releases really do go out faster and merge conflicts really do drop, split off a second one. Don’t carve your whole site into five or six sub-apps on day one, that’s just digging yourself a hole.
One line worth remembering: micro-frontends are a scalpel for big teams that can’t split any other way, not a decoration for small sites that haven’t grown up yet. If your team isn’t at that scale, splitting just turns a simple problem into a complicated one.