You add a field to an API response. To ship it properly, you open a pull request in the backend repo, another in the web app repo, a third in the mobile app repo, and then you coordinate three reviews and three deploys so nothing breaks in between.

Or you put everything in one repository and do it in a single pull request. Then six months later, CI takes forever, every push runs every test, and someone asks why the mobile developers need to clone the entire backend.

That's the monorepo vs polyrepo debate in two paragraphs. Neither side is wrong. They just move the pain to different places, and the trick is choosing the pain your team handles best.

The two options

• Monorepo: several projects live in one Git repository, usually in folders like apps/api, apps/web, apps/mobile and packages/shared.
• Polyrepo (or multi-repo): each project has its own repository, its own history, its own CI and its own release cycle.

One common confusion first: a monorepo is not a monolith. A monolith is one deployable application. A monorepo can hold many independently deployed services. How you store code and how you deploy it are separate decisions.

Where monorepos shine

Changes that cross projects

This is the big one. When the API, the web app and the mobile app change together, a monorepo lets you make the change in one pull request, review it as one story and test it as one unit. No "merge this first, then that" choreography.

Sharing code is just importing it

Shared TypeScript types, validation rules, UI components or API clients live in a packages/ folder and are used directly. With npm, pnpm or Yarn workspaces, there's nothing to publish and no version to bump.

One set of standards

One lint config, one formatter, one place for CI templates, one place to update a dependency everywhere. It's much harder for projects to quietly drift apart.

Where polyrepos shine

Clear ownership and access

Each repository has an obvious owner, and permissions are simple: a contractor working on the marketing site never sees the payments service. In a monorepo, access is usually all or nothing at the repository level.

Simple, fast CI by default

Every repo's pipeline only knows about its own code. Nothing to configure, nothing to filter, no chance of a docs change triggering the mobile build.

Independent lifecycles

A legacy system that changes twice a year, a fast-moving app and a shared library used by other teams can each move at their own speed and keep their own history.

Side by side

The costs nobody mentions up front

Monorepo: you must teach CI to build only what changed. On GitHub Actions, that can start as simple paths filters per workflow; larger setups use tools like Nx or Turborepo that understand the dependency graph and cache results. Without this, every push runs everything and developers start ignoring slow pipelines. Mixed stacks add friction too: a Laravel API and a React Native app have completely different tooling, and one repo doesn't make that disappear.

Polyrepo: shared code is the tax. You publish it as a package (a private npm package, or a Composer package via a VCS repository), version it, and update every consumer. In practice, consumers fall behind, and "which version of the shared types does the mobile app use?" becomes a real question. Cross-project changes need coordination and a careful deploy order.

What I'd do in a small team

For a small team building one product, say a Laravel API, a React web portal and a React Native app, I lean towards a monorepo for the product:

• Most features touch the API and at least one client, so single pull requests are a daily win.
• Shared TypeScript types between web and mobile stay in one place.
• With a few developers, everyone works across the stack anyway, so coarse access control isn't a real loss.
• Start with workspaces and per-app paths filters in CI. Add Nx or Turborepo only when builds actually get slow.

And I'd keep separate repos for things with a different lifecycle or audience: a marketing website, infrastructure code with restricted access, a library shared across unrelated products, or anything an outside contractor works on.

You can also mix: one monorepo per product, separate repos between products. That's often the most practical answer of all.

Signs you picked the wrong one

• Monorepo pain: CI is slow because everything builds every time; teams step on each other's changes; nobody knows who owns a folder.
• Polyrepo pain: most pull requests come in pairs or triples; shared packages are always several versions behind; bugs come from API and client being out of sync.

Both are fixable without migrating, at least for a while. CODEOWNERS and CI path filters fix a lot of monorepo pain; generated API clients and contract tests fix a lot of polyrepo pain.

The short version

• Monorepo: easy cross-project changes and sharing, but CI and ownership need work.
• Polyrepo: clear boundaries and simple CI, but shared code and coordination cost more.
• Small team, one product, features that cross projects: monorepo.
• Different lifecycles, audiences or access needs: separate repos.

Which setup is your team on right now, and what's the one thing you'd change about it?