Well, sure. if you have a pile of totally unrelated things that never need to change in lock-step, then you don't need a "monorepo." But on the other hand if yo

Well, sure. if you have a pile of totally unrelated things that never need to change in lock-step, then you don't need a "monorepo." But on the other hand if you're building an entire software system such as a collection of API services, a database schema, embedded device firmware, and a website, and all of these things are interdependent and incompatible across versions then please for the love of god use a monorepo. At my job our cloud team uses multiple separate repositories which makes sense, but it also moves the burden of versioning to run-time. This is because they have to interface with multiple different versions of the device firmware. So they deploy different run-time versions of the APIs to support legacy and current production firmware versions. But our firmware repository is a monorepo in that the sources and build system builds the artifacts for multiple devices from the same source tree. So it's not so cut and dried as "never use a monorepo" or "always use a monorepo." It involves engineering tradeoffs and decisions that are made in a context, and you can't extract your advice from the context in which it exists. What works for our cloud team would be a terrible mess on the embedded side simply because of how the software is deployed and managed.