Should I start a new project with microservices?

Short answer: probably not. For most greenfield products, the right starting point is a well-modularised monolith.

The real problem microservices solve isn’t technical, it’s organisational: independently deployable parts, owned by separate teams, that need to scale at different rates. If you’re a solo developer or a small team and the domain hasn’t fully settled yet, you have none of those problems — yet you’d be paying the full cost of a distributed system up front (network latency, partial failures, distributed transactions, observability, deployment complexity).

The path I recommend:

1. Start with a modular monolith. Split the domain into clear bounded contexts, but keep them in a single deployable application. Route inter-module communication through explicit interfaces — never reach straight into another module’s tables.
2. Enforce the boundaries in code. Don’t allow circular dependencies between modules. That discipline does 80% of the work in advance for the day you actually need to extract a module into a service.
3. Split when you’ve measured the pain. When a module genuinely has to scale separately, when a distinct team owns it, or when deploys start blocking each other — that’s when you promote that boundary into a service.

Microservices aren’t a goal; they’re a cost you pay at a certain scale. Don’t start paying it before you reach that scale. People say “extracting a service from a monolith is hard” — and it is — but extracting from a monolith with clean boundaries is far easier than fixing service boundaries you drew wrong from day one.