The real question is not the number of services, but the number of teams that must deploy independently.
Splitting into microservices solves an organisational problem before it solves a technical one. It lets several teams deploy without coordinating. With a single team it costs complexity and gives nothing back.
For the vast majority of projects we support, a well-structured modular monolith deployed by a single pipeline is the right answer for the first three years. Boundaries between modules live in the code, not on the network.
When growth justifies a real split, those internal boundaries become natural extraction points. You pull out one service at a time, when a concrete need demands it: a different release cadence, a specific load constraint, a dedicated team.