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. Then 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 splitting a frontend actually means
A micro-frontend architecture splits a product’s frontend into several independently built, tested and deployed pieces, each owned by a separate team. They get 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. A user sees one coherent product while the teams behind it ship on separate schedules.
The team size where this starts paying off
It earns its cost once you have genuinely separate teams, roughly four or more frontend developers split into distinct groups. They need to ship 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, 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, keeping a design system in sync, running separate CI pipelines, usually costs more 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 just anticipated. If the answer points toward “not yet,” we recommend a well-organized monorepo with clear module boundaries instead. That gets most of the organizational benefit without the runtime integration cost.
When it is the right call, module boundaries get drawn around team ownership first, not an arbitrary technical split. 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. Each module ships 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. That 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. It also pairs with serverless backend architecture, when each frontend module needs 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, the marketplace we are launching with a team of AI agents handling day-to-day operations.
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 usually costs more than it saves: shared dependency management, runtime integration, separate deploy pipelines. 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 full runtime integration is more complexity than the project needs.
Does this slow the app down for users?
It can, if done carelessly. 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. We 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. The shell and shared design system belong to a platform team, or whoever plays that role.