Insights · Architecture
Start with a monolith. Seriously.
Microservices solve organisational problems most young products don't have yet.
About once a month, a founder asks us to build their MVP as microservices "so it can scale". We usually talk them out of it.
What microservices actually buy you
Independent services let independent teams deploy independently. That is a huge win when you have eight teams stepping on each other. When you have three developers, it mostly buys you network calls where function calls used to be, distributed debugging, and several deployment pipelines to maintain.
A well-structured monolith scales further than you think
A single application with clear internal modules — billing, users, orders — each owning its own tables and talking through defined interfaces, can serve a very large number of users on modest hardware. Scale comes from caching, sensible database indexes and background job queues long before it comes from splitting services.
Keep the door open
We design monoliths so they can be split later:
- No module reads another module's tables directly.
- Slow or bursty work — emails, reports, image processing — goes through a job queue from day one.
- Every module has its own tests and could, in principle, be lifted out.
When a part of the system genuinely needs to scale or deploy on its own, it can be extracted in weeks rather than rewritten in months.
The rule of thumb
Split a service off when a team, not a technology, needs it. Until then, spend the complexity budget on your product.