I think the biggest argument in favour of monorepos is that both code and dependencies are version controlled. You can check out any commit and get a fully work

I think the biggest argument in favour of monorepos is that both code and dependencies are version controlled. You can check out any commit and get a fully working environment, knowing that each module will be at the right version that's compatible with the other modules. Without this, you need to have some infrastructure to handle these dependencies, for example by agreeing on version numbers, making sure dependency versions of all modules in all repositories are correctly updated, etc. Maybe also scripts to rollback everything to a different versions. There are tools for this of course, but the nice thing with a monorepo is that it's built-in - it's all in the commit history. So when you say the org needs cash and skills for monorepo maintenance, I actually think it's the other way around. I've seen companies splitting each module in its own repository, but with no tooling to get dependencies right, and the whole thing was a mess. You can't know what commit of what repo is compatible with another commit of a different repo. Had they used a monorepo they wouldn't have this problem, because a commit either build or not, there's no unknown dependencies.