Monorepo, polyrepo, or just fewer repos?

The question behind the question

Arguments about monorepos usually become arguments about tools. The useful question is simpler. When someone makes a change, how often does it need to land in more than one repository at the same time?

If the answer is "often"

Shared types, a common design system, an API and the client that calls it: when these change together, splitting them across repos creates coordination work. You'll cut releases in one place, wait, update another place, and keep version numbers in sync by hand. A single repository removes that.

If the answer is "rarely"

Independent services with clear contracts and separate owners can live happily apart. Separate repos give clear ownership and simple access control, and each one stays small enough to understand.

The option nobody mentions

Often the real problem is that a small team has fifteen repositories. Each one has its own pipeline, dependencies and conventions, and each is a little out of date. Fewer repos, even just merging the ones that always change together, fixes more than any tool.

What goes wrong in each

• Monorepo: slow builds and test runs, unclear ownership, and everyone able to break everyone. These need tooling and discipline to manage.
• Polyrepo: drift. Shared code gets copied instead of shared, and nobody can say which version of what is running.

What to do this month

1. Look at your last 20 changes. Count how many touched more than one repo.
2. Merge what always moves together. Start with two repos, not twenty.
3. Write down ownership. Who approves changes to each area, whatever the layout.
4. Measure build and test time. If it's past ten minutes, fix that before choosing tools.
5. Pick one pipeline template. Whatever layout you choose, standardize how things build and deploy.