Products that consist of several coordinated applications — a customer app, an operator or admin console, and a driver or partner app, for example — face an early structural decision: one repository for everything, or a separate repository per application. Both work. The choice depends on what the applications actually share.
The case for a monorepo
When applications share a meaningful amount of code — a design system, API client types, validation logic, or business rules that must stay in sync — a monorepo keeps that sharing honest. A shared type changes once, and every application that depends on it is forced to update in the same commit, rather than drifting out of sync across repositories that release independently.
A monorepo also makes cross-application changes visible in a single pull request: adding a new field to an order, for instance, touches the API, the customer app, and the operator console together, and a reviewer can see the whole change at once.
The case for separate repositories
Separate repositories work well when the applications are more loosely coupled than they first appear: different release cadences, different teams with different access needs, or genuinely independent codebases that only communicate through a stable, versioned API. Splitting reduces the blast radius of a broken build — a failing test in one application cannot block deployment of another — and keeps CI times shorter as each repository grows.
A practical middle ground
Most multi-application products are not purely one or the other. A common and effective pattern:
- A monorepo for the applications and packages that share code directly (shared UI components, a common API client, validation schemas).
- A separate repository for infrastructure or services that are genuinely independent and versioned through a stable contract, such as a public API or a data pipeline.
The decision is easier to change early than late. Tooling for splitting a monorepo into multiple repositories, or the reverse, exists — but both are disruptive once a team has built habits and CI pipelines around one structure. Decide deliberately at the start rather than by default.
What actually determines the right answer
Two questions settle most of these decisions in practice: how much code genuinely needs to be shared and kept in lockstep, and how independently the teams working on each application need to release. Products with heavy sharing and a single team lean toward a monorepo. Products with loose coupling and separate teams lean toward separate repositories with a well-defined API between them.