How do you manage one frontend codebase shared by multiple teams?

[giorgiPapava]

Looking for advice from teams who've been here. We have a React + TypeScript + Refine + Vite admin panel hosting 5 separate apps ("gateways") in a single repo / single Vite build. Each gateway has its own backend API, its own team, and is fairly self-contained:

• Isolated routes, data provider, access control, permissions, and i18n namespace per gateway
• A central registry wires them together (data providers, access control, routes, app-switcher, types)
• A productionReady flag hides beta gateways from prod
• Shared infra: auth (OIDC), UI primitives (shadcn), a shared DataTable, env validation

It works, but with 5 teams in one repo we keep hitting friction:

1. Releases / branching — All teams commit to a shared test branch, so commits get mixed across gateways. To ship one gateway we cut a release branch and cherry-pick that gateway's commits out of the mix. Fragile and manual. How do you ship independently on a shared trunk?

2. Independent deploys — Single build means one team's change rebuilds/redeploys everyone. We've prototyped Module Federation / micro-frontends, but it's a big jump in complexity. Worth it for 5 teams, or overkill?

3. Ownership boundaries — No CODEOWNERS yet, any team can touch any gateway. CODEOWNERS, separate packages, enforced monorepo boundaries — what worked?

4. Shared code coupling — Our registry has circular-dependency landmines, and we're mid-migration to a shared npm package. Monorepo (pnpm/Nx/Turborepo) vs. published package vs. just discipline — what scaled?

Core question: for ~5 teams each owning a domain app in one frontend, would you stay monolith + good module boundaries, go monorepo with separate packages, or full micro-frontend? What did you regret?

Thanks 🙏

[Bibek200619]

For ~5 teams, I would not jump to micro-frontends yet. I’d first move from the current “one app with internal gateways” structure to a monorepo containing independently buildable apps + shared packages.

Something along these lines:

apps/
gateway-a/
gateway-b/
gateway-c/
gateway-d/
gateway-e/

packages/
auth/
ui/
data-table/
config/
types/

Each gateway would still live in the same repository and use the same trunk, but it would have its own build and deployment pipeline.

[karkik01]

For five teams, I would not jump to micro-frontends yet. Your main problem sounds less like runtime architecture and more like ownership and release boundaries.
I’d keep the monorepo, but stop treating the frontend as one indivisible application internally.
I would structure each gateway as an independently owned workspace/package, with shared packages for things such as authentication, UI primitives, common types, API contracts and infrastructure. Then put explicit dependency rules around those packages so gateways cannot reach into each other’s internals.
The central registry is fine, but it should stay very small. Ideally it should only know things such as:
routes
data provider registration
permissions
navigation metadata
feature availability
It should not become a place where gateway-specific business logic accumulates.
For releases, I would also get rid of the shared long-lived test branch. Use trunk-based development with short-lived branches and merge continuously into main. CI should determine affected packages and only run/build what changed plus anything that depends on shared packages that changed.
With Nx, Turborepo or even a straightforward pnpm workspace setup, you can get:
independent ownership
affected builds/tests
caching
clear package boundaries
separate deployment pipelines
without taking on the operational complexity of Module Federation.
I’d also add CODEOWNERS immediately. Each gateway should have an owning team, and shared packages should require review from their maintainers. That usually removes a surprising amount of cross-team friction.
The important distinction is:
monorepo does not mean monolithic deployment
You can keep one repository while producing multiple deployable applications if independent releases become important.
I would only introduce micro-frontends once you actually need runtime independence, for example teams deploying incompatible frontend stacks or loading independently versioned applications at runtime. For five React/TypeScript teams already sharing auth and UI infrastructure, that complexity is probably premature.
So my progression would be:
current monolith -> workspace monorepo with enforced boundaries -> independently deployable apps if required -> micro-frontends only if runtime independence becomes a real requirement
The thing I would avoid most is solving the branching problem with architecture. Fix ownership, package boundaries and CI/CD first.