The monorepo versus polyrepo debate gets argued with the intensity of a religious war, usually by pointing at what Google or some other giant does. That is the wrong way to decide it, because their constraints are nothing like yours. For a startup, this is not really an architecture question. It is a coordination question: how do you want your team to share code, make changes across boundaries, and stay in sync. The right answer depends on your team's size and how it works, not on a big company's example.
Key Takeaways
- Monorepo vs polyrepo is a coordination decision, not a pure architecture one.
- For a small team, a monorepo is usually simpler: one place, atomic cross-cutting changes.
- Polyrepo suits independent teams owning independent services with clear boundaries.
- Do not copy Google's monorepo or Amazon's services model; your constraints are different.
What the Choice Actually Trades
A monorepo puts all your code in one repository. The appeal for a small team is real: one place to look, one version of everything, and the ability to make a change that spans the frontend, the backend, and shared code in a single commit without coordinating across repos. The cost shows up at scale, when the repo grows large and you need tooling to keep builds and tests fast.
A polyrepo splits code into many repositories, often one per service or app. This gives each team clear ownership and independence: they deploy on their own schedule and are not entangled in everyone else's code. The cost is coordination, because a change that spans repositories now means multiple commits, version bumps, and careful sequencing.
| Factor | Monorepo | Polyrepo |
|---|---|---|
| Small team | Simpler, one place | Overhead without benefit |
| Cross-cutting changes | Atomic, one commit | Multiple coordinated commits |
| Independent team ownership | Weaker boundaries | Strong boundaries |
| Tooling burden | Grows with repo size | Distributed across repos |
A Concrete Version
Picture a startup with six engineers building one product with a frontend, a backend, and some shared types. A monorepo fits naturally: when someone changes a shared type, they update every place that uses it in one commit, everyone sees the same code, and there is no dance of publishing a package and bumping versions across repos. Now picture a later stage with several teams owning genuinely separate services that deploy independently and rarely touch each other's code. Here polyrepo boundaries can help, because each team moves without stepping on the others. The same company might sensibly start monorepo and split later, when independence starts to matter more than shared-change simplicity.
The Honest Counterpoint
Neither approach is universally right, and the simple story has exceptions. A monorepo can work at large scale, Google runs one, but only with serious investment in build and test tooling that a startup should not be building early. Polyrepo can suit a small team too, if they are genuinely building independent things with little shared code. And the choice is not permanent: teams move between them as they grow, and treating it as an irreversible, identity-defining decision is a mistake. Pick the one that fits how your team works today, and change it when how they work changes.
What This Means for Your Team
The monorepo-versus-polyrepo question is really about how much your team needs to coordinate, and that changes as you grow, so let the decision follow your team rather than a big-company blog post. Early, when everyone is in the same product, a monorepo usually reduces friction. Later, as independent teams and services emerge, polyrepo boundaries can pay off, which ties into the broader challenge of scaling an engineering team from 5 to 20. Whoever owns this call should be a senior engineer who reasons from your actual constraints, not from what a company a thousand times your size does. See available engineers.
Frequently Asked Questions
Should a startup use a monorepo or polyrepo?
For a small team building one product, a monorepo is usually simpler: one place for everything and atomic cross-cutting changes. Polyrepo fits later, when independent teams own independent services with clear boundaries.
Why not simply copy what Google does?
Because Google's constraints are nothing like a startup's. Its monorepo works only with enormous investment in build and test tooling you should not be building early. Decide from your own team's size and workflow.
Is the monorepo vs polyrepo choice permanent?
No. Teams move between them as they grow. Many start with a monorepo and split into a polyrepo later when independent ownership matters more than shared-change simplicity. Treat it as changeable.
What is the main downside of each?
A monorepo needs tooling to stay fast as it grows large. A polyrepo adds coordination cost, since changes spanning repositories require multiple commits and careful version management.
The Bottom Line
Stop deciding monorepo versus polyrepo by pointing at Google or Amazon. It is a coordination decision, and your coordination needs are set by your team's size and how it works, not by a giant's example. A small team building one product is usually better served by a monorepo's simplicity and atomic changes; independent teams owning independent services benefit from polyrepo boundaries. Choose for today, and change it when your team does.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
