Small decisions at the beginning of a project can sometimes have much larger and difficult to predict impacts later on. Version control and repository layout are one of those areas where it is important to think ahead and avoid the need for awkward check-in procedures or messy restructuring later.

Mono vs Multi Repo

The monorepo vs multirepo issue is about balancing ease of management (particularly at the beginning of a project) with modular design and loose coupling.

The risk with a multirepo strategy is that it may introduce dependency loops which will lead to build and reliability issues.

With a monorepo the issue is that build and test must look at all of the systems / code at every check-in. This means longer development cycles, build platform complexity and development systems that require the full suite of tooling etc.

The solution is to understand the major components and the way that they interact within the system as a whole. Dependencies should be unidirectional and repositories should be cohesive, that is, have one responsibility.

Consider the functionality of the component in question. Will it be used across other components? If so, consider creating a new repository.

This will likely mean some increased complexity in the build / test / deploy process but if done judiciously it should be manageable.

This also means that you may need to split functionality out of a repo and re-work the build pipeline from time to time.

No solution is perfect but this seems to balance the pragmatic need to get things done while preserving agility.