It isn’t as black and white as you are portraying it. You can go too far in the microservices direction, and you can go too far towards a monolith. There’s a

It isn’t as black and white as you are portraying it. You can go too far in the microservices direction, and you can go too far towards a monolith. There’s a sweet spot. I currently think that this sweet spot is around one service per “team” (around no more than 10 people). This lets teams operate and deploy their services independently, while still retaining some of the cohesiveness of a monolith. It also lets the company “refactor” engineering teams by moving service ownership around. There are definitely legitimate reasons for a team to own multiple services though (organizational changes, differences in scale, security constraints, etc.). Monoliths shared across dozens of people are operational nightmares because there’s not a strong sense of operational ownership, so you often end up with a bunch of process and bureaucratic overhead to compensate. Your advice to start with a monolith is too simplistic. If you know how your service will scale and your engineering teams will grow, then you have enough information a priori to avoid the waste of attempting to split apart a monolith later.