If you’re scoping a new product, at some point someone on the team will ask: should we build this as microservices from day one, or keep it simple? This is for founders and CTOs making that call before a single line of code is written — and for anyone who inherited a monolith and is being told it “needs to become microservices” without a clear reason why. Here’s how to think about the monolith vs microservices decision properly, and what actually determines the right answer for your stage.
Why founders get talked into microservices too early
Microservices have a good reputation. Big, well-known engineering organisations run them at scale, and it’s easy to conclude that “proper” software is built that way from the start. Combine that with a new hire who’s used microservices at a larger company, or a consultant keen to sell a more elaborate build, and a five-person startup can end up committing to a distributed system before it has its first paying customer.
The problem is that microservices solve an organisational problem before they solve a technical one. Their real payoff — teams shipping independently, services scaling separately, blast radius contained — only shows up once you have enough engineers and enough traffic that a single codebase and a single deploy pipeline are genuinely slowing you down. Below that point, you’re paying the tax (network calls where function calls used to be, distributed debugging, duplicated infrastructure, more moving parts to secure and monitor) without collecting the benefit.
The case for starting with a monolith
For an early product, a well-organised monolith is usually the faster, cheaper, and more reversible choice. Everything lives in one codebase and one deployable unit, so there’s no network boundary between the parts of the system that change together, no service discovery to configure, and no question of which service owns which slice of a transaction. You can refactor across the whole system in one pull request instead of coordinating changes across five repositories.
This isn’t just theory. Twilio Segment’s engineering team publicly documented moving in the other direction — from over 100 microservices back down to a single service — after finding that the operational overhead of running that many independently deployed pieces was consuming more engineering time than it was saving. Three full-time engineers were needed just to keep the fleet of services alive. That’s an extreme case, but it’s a useful reminder that microservices are a cost you take on deliberately, not a default you get for free.
If you’re still validating the product itself, this matters even more. A well-scoped MVP should be optimised for how fast you can learn and change direction, not for a scale problem you don’t have yet. Splitting a product you might pivot twice over the next year into separately deployed services just multiplies the cost of every pivot.
Monolith vs microservices: what a modular monolith actually looks like
The mistake isn’t choosing a monolith — it’s choosing an unstructured one. A monolith that lets every part of the codebase reach into every other part will eventually become the tangled, change-anything-break-everything system that microservices were invented to escape. The fix is a modular monolith: one deployable application internally organised into clearly bounded modules, each with an explicit interface and its own area of the database.
Shopify is the widely cited example here: its core product is still one large Rails application, but internally it’s broken into components with enforced public interfaces, so teams can work on billing, checkout, or inventory without quietly coupling to each other’s internals. The result is most of the simplicity of a monolith with a good chunk of the organisational clarity people reach for microservices to get.
What good module boundaries need
- A clear owner and a defined public interface for each module — no reaching into another module’s internals or database tables directly
- Domain boundaries that match how the business actually works (billing, auth, catalogue, notifications), not technical layers
- A data model designed with those boundaries in mind from the start — retrofitting them onto a tangled schema is much harder than establishing them early, which is why database schema design deserves real attention even in an MVP
- Automated checks (linting, architecture tests, or tools like Packwerk at Shopify) that stop new code from quietly violating the boundaries you’ve set
Get this right and splitting out a genuine microservice later, if you ever need to, is a matter of extracting a well-defined module rather than performing surgery on a codebase with no internal seams at all.
Signals it’s actually time to split something out
Microservices earn their keep when you have a specific, current problem, not a hypothetical future one. Watch for these signals rather than a calendar date or headcount milestone:
- Independent scaling needs. One part of the system (image processing, a search index, a webhook receiver) has load characteristics wildly different from the rest, and scaling the whole application to serve it is wasteful.
- Team boundaries causing real friction. Multiple teams are regularly blocked on each other’s release schedules, or a deploy for one feature keeps breaking an unrelated one.
- A module with a genuinely different lifecycle. Something needs a different tech stack, security posture, or compliance boundary — for example isolating payment handling.
- The codebase itself, not the org chart, is the bottleneck. Build times, test suite duration, or onboarding time have become the limiting factor on shipping speed, and better modularity within the monolith hasn’t fixed it.
If none of these apply yet, the honest answer is usually “not yet” — and that’s a fine answer. It’s the same discipline behind avoiding a premature rebuild in SaaS product development generally: the expensive mistake is rarely picking the “wrong” architecture on day one, it’s re-architecting for a scale problem that never actually materialises.
How to move gradually, without a risky rewrite
When the signals above do show up, you don’t need to throw away the monolith. Extract one bounded module at a time, behind the interface you (hopefully) already defined, and put a service boundary around it once it’s proven stable in isolation. This is the same incremental approach we’d recommend for any legacy application modernisation: replace load-bearing walls one at a time, keep the system shippable throughout, and validate each extraction against real production traffic before you rely on it. A big-bang rewrite into “proper microservices” is where most of the horror stories in this space actually come from.
The bottom line
Start with a monolith, structure it as if you might split it later, and treat microservices as a deliberate answer to a problem you can point to — not a starting assumption. That gets you to market faster, keeps your options open, and means that if you do need to split the system apart, you’re extracting well-defined modules rather than untangling spaghetti under deadline pressure. If you’d like a second opinion on how to structure a new build or an existing codebase for this, book a free consultation and we’ll talk through what actually fits your stage.
FAQ
Should a brand-new startup ever start with microservices?
Rarely. Unless you already know you need to isolate a specific part of the system for compliance, security, or a genuinely different scaling profile, a modular monolith gets you to market faster with far less operational overhead.
Is a monolith bad for scaling?
Not in itself. Plenty of high-traffic products run on a well-structured monolith for years. What doesn’t scale is a monolith with no internal boundaries, where every change risks breaking something unrelated.
How do I know if my monolith is becoming a problem?
Watch build and test times, how often unrelated features break together, and how long it takes a new engineer to make a safe change. Rising numbers on any of those are a better signal than “we’ve hit X users.”
Does choosing a monolith now make it harder to move to microservices later?
Only if you skip the modularity work. A monolith with clear module boundaries and defined interfaces can be split incrementally. It’s an unstructured monolith that makes any future split expensive.
