i’d say it’s less that it’s inadequate, and more that it’s complex

for a small team, build a monolith and don’t worry

for a medium team, you’ll want to split your code into discreet parts (libraries shared across different parts of your codebase, services with discreet test boundaries, etc)… but you still need coordination of changes across all those things, and team members will probably be touching every part of the codebase at some point

for large teams, you want to take those discreet parts and make them fairly independent, and able to be managed separately: different languages, different deployment patterns, different test frameworks, heck even different infrastructure

a monorepo is a shit version of real, robust tooling in many categories… it’s quick to setup, and allows you a path to easily change to better tooling when it’s needed

I would say it's the other way around. The only reason monorepos aren't used more is because the tooling for monorepos is inadequate, or because people don't know how to use them.

I can't deny that the tooling for multi-repos is crap too though.

Version control tooling is still at its “blackberry” stage anyway.

That was uncalled for.