I prefer monorepo for tightly coupled systems (like a game server and client), and multi repo for multiple, loosely coupled systems (like a web API and mobile app). The main problem with monorepos is that without the resources to build proper tooling, you end up with useless commit logs and losing track of context while working, but once you're on a larger team the advantages may be better. However, if you have multiple teams working on different, a multi repo might be better; for example, if you have a team for your API and a different team for your website, then multiple repos might be better depending on how coupled they are.

Either way, it doesn't really matter that much. In the end, it's mostly just a personal preference.

Mono unless you have a great reason not to. Frontend and backend parts of the app can be a good reason, so you don't have to clutter either with stuff related to builds etc..

Going multi first is just too annoying to manage and doesn't make much sense. Also, it's more repos you have to get running on your device, and more room for divergence.

It gets even worse when small companies insist on creating their own packages...

Also, I usually have a repo that is for deployment-focused stuff, like kubernetes configs. These are good reasons. I think maybe a "scripts" or "scratch file" or a mix of the two can also be its own repo, for stuff that doesn't really belong anywhere specific and isn't getting called by other code.

Multi. Always.

The question with monorepos is not if they will become a nightmare. It is when they will become a nightmare.

Making a multirepo feel like a single workspace is trivial. Making a part of a monorepo feel like a repo from a multi repo is impossible.

Mono all the way.