If that's the reason, that's a great use-case for it. I am looking at it from a green fields perspective, and it seems more profitable to start with my company's codebase split up into packages from the outset, and focus on building tooling to handle package dependency version management instead of building tools to handle monorepos. The existence of large companies using monorepos creates some cargo cult pressure on those trying to make a decision which path to take, and so I think it's important to discuss what is really the goal to determine the best fit for my own use-case.

For what it's worth, I work on a project that is split into multiple repos that we now wish was a monorepo. Internal versioning issues are complex and end up eating a lot of time in our CI/CD workflow when they deliver no actual value to the end customer, since it all ships as one discrete unit. Ultimately we have a couple of FTEs that are basically hand-picking commits out of different repos to try to assemble a complete system of all versions that integrate with eachother. If we were working in one repo and kept breaking interface changes in feature branches this work would be significantly reduced, and the improved visibility of those cross-cutting changes would probably also motivate a faster turnaround time on them.

I would think that versioning and compatibility issues are the main driver of monorepos - if you are ultimately shipping one product, why get wrapped up in all the labor that can be involved in breaking it down while still being able to pull off working versions to test? Might be a much better decision to just treat it as one giant repo that always stays in a working state.

And finally, as a more soft-factors issue, I think that a monorepo can help to reduce siloization. We sometimes have issues with teams not liking it when people mess with "their" repo, which slows down cross-cutting changes by a huge factor. A monorepo would probably be a powerful factor against this kind of thing.

These are good observations. What about if you're explicitly not shipping all the code to each client, but have individual projects per client? Some of these criticisms still apply, but it seems more natural to have a repository per client/project when you're building bespoke solutions, or customizations from an inventory of shrink-wrapped solutions. [And clients must only see their own code.]

If the problem is the usability of multiple repositories, could this be solved with better tooling? Projects like GVFS suggest that monorepos do not avoid a need for strong tooling.

It's a cultural question like tabs versus spaces as much as anything: there are tools to support both, developers with plenty of opinions on both sides, many of which vary from language to language/environment to environment. Some languages have great package dependency systems, other languages excel when more of the code is more directly accessible.

It's easier for junior developers to deal with monorepos and it takes certain architecture considerations to plan for a strong component model and version management of that. Would you expect to have the right mix of senior-level staff to junior-level staff to handle that? What sort of turnover might you expect?

Furthermore, many monorepos sometimes don't happen intentionally, they just grow organically. It's sometimes only in hindsight where you realize that what you thought of as one system, one component, could have been cut into smaller pieces. It's sometimes only in hindsight where you realize that something you thought of as an internal-only API you didn't wish to version and package and support as such should have been componentized and versioned and packaged separately.

On both sides of the monorepo/small-packages spectrum there are continual trade-offs of time versus planning versus skill level, and neither is necessarily the "right" answer, and likely what you end up doing is somewhere in the middle, some combination of both, based as much on pragmatic needs as anything else.

When you say "start your company", I assume a small total repo size. I would say definitely go for a single repo, every time, all the time. Internal version dependencies can be surprisingly hard to handle even with a handful of components/apps.

It is extremely unlikely that your companys code size would become too much to handle in a single repo. And before that, imho it's just premature optimization to split things up.

While it's possible for it to become premature optimization, there is a level of division that hits a sweet spot that should absolutely be done up-front. I think it is not unreasonable to have a repository per project, and have another "Core" repository for code you factor out of individual project repos for reuse. As the core becomes more complex, you are then already set up to handle it.

Likewise, if you don't write at least some documentation up-front, you're much more likely to never get it done at all.

Based on my experiences, I would disagree. The "core" becomes a mess of versions and dependencies - you still need ALL the other repos to be able to change the code/data there to check all dependencies.

Just split with folders within the repo.

Anyways this is my opinion, and I know many wise people that disagree with me. And I've seen companies work well with both multiple and single repo.

I.e. your mileage may vary.