Several teams, one product:
deployed without stepping on each other
A single frontend codebase works fine until three or four teams are shipping into it at once and every release becomes a coordination problem instead of a deploy. Micro-frontends split a product into independently deployable pieces owned by separate teams, stitched together at runtime, so one team's release does not wait on another's.
What it is
A micro-frontend architecture splits a product’s frontend into several independently built, tested and deployed pieces, each owned by a separate team, composed together at runtime (most often through Module Federation) into one experience for the end user. A shell application handles routing and shared layout, loading each team’s module when needed, so a user sees one coherent product while the teams behind it ship on separate schedules.
When you need it (and when you do not)
It earns its cost once you have genuinely separate teams, roughly four or more frontend developers split into distinct groups, shipping into the same product often enough that coordinating one shared release has become a real bottleneck: a release calendar everyone has to sync to, a shared codebase where one team’s half-finished feature blocks another’s deploy. A multi-vendor marketplace platform and our own ProBay marketplace both reached this scale, several distinct areas of functionality (seller tools, checkout, catalog) that benefit from independent ownership.
It is the wrong tool for a team of two to five developers on one product; the operational overhead, managing shared dependencies across modules, keeping a design system in sync, running separate CI pipelines, usually costs more in complexity than the coordination problem it solves at that size. We say this up front because selling micro-frontend architecture to a team that does not need it yet is a bad trade for both sides.
How we build it
We start by confirming the team structure actually justifies it: how many distinct teams, how often does one team’s release currently block another’s, is the pain real or anticipated. If the answer points toward “not yet,” we recommend a well-organized monorepo with clear module boundaries instead, which gets most of the organizational benefit without the runtime integration cost.
When it is the right call, module boundaries are drawn around team ownership first, not an arbitrary technical split, since a boundary that does not match who actually works on what just moves coordination problems around instead of removing them. The shell application handles shared concerns, routing, authentication state, the design system, so individual modules stay focused on their own domain. Module Federation is our default integration mechanism, letting each module ship its own bundle while sharing framework and design system code as externally loaded singletons, avoiding the duplicated-dependency bloat that sinks careless micro-frontend setups.
Each team gets its own CI/CD pipeline, deploying independently once their module passes its own tests, which is the actual point of the architecture: a release is a team’s decision, not a company-wide event. For projects migrating an existing monolith frontend, we extract one module first as a proof of the pattern before committing to splitting the whole codebase.
What to watch
The biggest risk is shared dependency bloat: if every module bundles its own copy of React and your design system, the composed app loads slower than the monolith it replaced, defeating the purpose. We manage this explicitly with shared singletons and measure real load time, not just module count, as the success metric. Cross-module communication needs discipline too, modules reaching directly into each other’s internals recreates the tight coupling this architecture was meant to avoid; we define a narrow, explicit contract for how modules talk to each other and the shell. And this architecture has a real floor team size below which it is not worth the overhead, which we assess honestly before recommending it.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Shell plus first module | from $5,000 | Architecture, shell app, Module Federation setup, one module extracted | 4 to 6 weeks |
| Full migration, several modules | from $12,000 | Shell, shared design system integration, multiple modules, CI/CD per team | 6 to 10 weeks |
Running cost is hosting for the shell and each module, typically $50 to $300 a month depending on the number of modules and traffic.
Related
This pairs with design system and component library as the shared layer every module should build on, and with serverless backend architecture when each frontend module is paired with its own backend service. See the development service page for our full build process. For real examples, see the multi-vendor marketplace platform and ProBay, our own marketplace run by a team of AI agents.
Is your frontend release calendar the actual bottleneck? Get in touch and we will tell you honestly if micro-frontends are the fix or if your team is not there yet.
FAQ
How much does a micro-frontend setup cost?
From $5,000 for the architecture, a shell application and the first module split out, 4 to 8 weeks. A full migration of an existing large monolith frontend into several modules runs $10,000 to $20,000 depending on how entangled the current codebase is.
Do we actually need this, or is it overkill?
For most teams, overkill. Micro-frontends solve a coordination problem that shows up with roughly four or more frontend teams shipping into the same product; below that, the added complexity, shared dependency management, runtime integration, separate deploy pipelines, usually costs more than it saves. We will tell you honestly if a well-organized monolith frontend or a monorepo is the better fit for your actual team size.
What is the integration mechanism?
Module Federation, built into Webpack and supported by Next.js and Vite, is our default: each module ships its own bundle and the shell loads them at runtime. We also use simpler approaches, iframe-based isolation or build-time composition, when the full runtime integration is more complexity than the project needs.
Does this slow the app down for users?
It can, if done carelessly, since loading several independent bundles risks duplicated dependencies and extra network requests. We manage shared dependencies (React, the design system) as externally loaded singletons so each module does not ship its own copy, and measure the composed app's real load time against a single-bundle baseline.
Who owns which part of the code?
Whichever structure matches your actual teams: each module lives in its own repository or its own folder in a monorepo, owned and deployed independently by the team responsible for it, with the shell and shared design system owned by a platform team or whoever plays that role.