Not "are microservices better," but: does a specific part of this system need to scale, deploy, or be owned independently from the rest — badly enough to be worth the network calls, eventual consistency, and operational overhead described above?
A small team building a new product almost always ships faster as a monolith first — there's no organizational coordination problem yet (see Conway's Law, above) to justify splitting team ownership, and no traffic pattern yet that actually needs one module scaled independently of the rest. The teams that benefit most from microservices are usually ones that already have a monolith and have hit a real, specific pain point — one team blocked on another's deploy schedule, or one module that needs 50x the compute of the rest — not ones starting from a blank repository trying to guess their future scale. When that pain point does show up, a modular monolith with honest internal boundaries and a strangler-fig extraction plan is a much lower-risk path to a real service than a rewrite.