When you're organizing your code, you essentially have two choices – tracking changes in many smaller repositories or tracking changes in a single large repository. This is the age-old debate of "monorepos(itories) vs. multi/poly repos".

Monorepos have U-shaped utility. They are great for extremely small or extremely large organizations, and terrible for everything in between. Why's that?

Scaling with a monorepo. Google, Microsoft, Facebook, Uber, Airbnb, and Twitter all use monorepos. Why?

Starting with a monorepo. This is not as popular of a strategy, but I believe that starting with a monorepo is often the right choice.

The trough of despair. If you're a medium size organization, monorepos can be tough. You'll need to build bespoke tooling to handle most things.

If I were starting a project today, I'd most certainly start off with a monorepo. As services start to evolve and the application becomes more complex, I'd split it into the minimum number of repositories, making sure that highly dependent services still stayed in the same repository.