# Should I start a new project with microservices?

> For most greenfield products, start with a modular monolith and enforce boundaries in code, promoting a module to a service only when it must scale alone.

- Asked: 2026-05-20
- Answered: 2026-05-22
- Asked by: Emre
- Tags: mimari, mikroservis
- Source: https://www.muhammetsafak.com.tr/en/just-ask/should-i-start-a-new-project-with-microservices/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** I'm starting to build a new product and we're still a small team. I'm thinking about setting up the architecture with microservices from the very start — beginning "the right way" up front feels sensible so I don't suffer later when I need to scale. But this early on, is the complexity microservices bring worth it, or should I start with a monolith? For a greenfield project, what would you recommend?


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

## Short answer

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.

## Why

1. **You pay the cost up front and collect the benefit later.** Network latency, partial failures, distributed transactions, observability and deployment complexity are billed from day one; the need to scale parts separately arrives months later — or never.

2. **A boundary drawn before the domain settles is drawn wrong.** Placing a service boundary while you're still learning what the product is means casting that boundary in concrete, over the network.

3. **Fixing a wrong service boundary is harder than extracting from a monolith.** 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.

## What to do

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 most 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. I walked through how to run that day in [peeling the payment module off a monolith with Strangler Fig](/en/just-ask/peeling-the-payment-module-off-a-php-monolith-with-strangler-fig/).

**Bottom line:** microservices aren't a goal; they're a **cost** you pay at a certain scale, so don't start paying it before you reach that scale. I'd start with a modular monolith, enforce the boundaries in code, and promote a module to a service only when measured pain shows up. I unpack the full architectural reasoning on sade.dev.

## Related Reading

- [Why I Start Projects With a Modular Monolith](https://sade.dev/en/journal/why-i-start-with-a-modular-monolith) — sade.dev
- [When I Move to Microservices](https://sade.dev/en/journal/when-i-move-to-microservices) — sade.dev
- [How do I peel the payment module off a PHP monolith with Strangler Fig?](https://www.muhammetsafak.com.tr/en/just-ask/peeling-the-payment-module-off-a-php-monolith-with-strangler-fig/) — Just Ask
- [How do I set up distributed tracing (OpenTelemetry) across microservices?](https://www.muhammetsafak.com.tr/en/just-ask/distributed-tracing-with-opentelemetry-across-laravel-and-go/) — Just Ask
- [For the message schema between Laravel and Go services, Protobuf or JSON Schema?](https://www.muhammetsafak.com.tr/en/just-ask/message-schema-between-laravel-and-go-protobuf-or-json-schema/) — Just Ask