Introduction
Microservices are popular because successful companies use them. What founders forget is that those companies had millions of users before adopting them.
Startups should optimise for speed, clarity and maintainability. Not theoretical scale. Most startups choose microservices years before they need them, and pay the operational cost from day one against benefits that may never arrive.
This framework helps you decide whether the next step is a monolith, a single new service or a deliberate split, and when the cost of splitting is genuinely earned.
What it solves
What microservices solve well
-
Independent deploys at organisational scale
When multiple teams need to ship without coordinating release windows, microservices give each team its own deploy boundary. Useful at 30+ engineers; rarely useful at 3.
-
Independent scaling of hot paths
When one part of the system has wildly different load characteristics than the rest, splitting it lets you scale it separately. Real benefit; almost always a problem you discover, not predict.
-
Technology heterogeneity
Different services can use different languages, databases or runtimes where it matters, ML pipelines next to web stacks next to data warehouses. Useful at scale, unnecessary at the start.
-
Failure isolation
A bug in one service does not bring down the others. Powerful at high scale, oversold at low scale; a monolith with good error handling fails less often than a poorly-designed microservice mesh.
-
Clearer ownership boundaries
Services correspond to teams. When the org has stable teams with distinct responsibilities, microservices match the structure. When the org is small, they impose a structure that does not exist.
What it does not solve
What microservices will not fix
-
Slow product decisions
Architecture cannot speed up a team that takes weeks to decide what to build. A microservice mesh built on slow decisions ships slowly.
-
Tangled code
Bad code in a monolith becomes bad code in many services. Splitting badly-shaped logic into smaller pieces preserves the badness, and adds network calls between the pieces.
-
Lack of testing discipline
A monolith without tests is fragile. A microservice mesh without tests is fragile and distributed. Discipline is upstream of architecture.
-
Insufficient operational maturity
Microservices multiply operational surface area. A team that does not have monitoring, alerting and on-call sorted for one service has no business running ten.
-
Unclear ownership
Services need owners. Without clear ownership, microservices produce silent bystanders and accidental shared databases. Org clarity precedes architectural splits.
Decision tree
Six questions before you split
Run the proposed split through these questions. The honest answers usually say 'monolith for now'.
- Question 01
How many developers work on the system?
No → If the answer is under ten, almost certainly monolith. Microservices pay back through team independence, and one team needs zero independence from itself.Yes → Confirm with a real coordination cost, release conflicts, merge conflicts, blocked deploys. Without those costs, the case is academic. - Question 02
Can one codebase still be managed effectively?
No → Investigate the source. Most 'unmanageable monolith' problems are bad code organisation, not the monolithic shape itself.Yes → Continue. Manageability is a function of code quality and discipline, not number of repos. - Question 03
Are deployment bottlenecks occurring?
No → Wait. Splits driven by hypothetical bottlenecks tend to produce real bottlenecks elsewhere.Yes → Quantify them with concrete examples and dates. Specifics beat opinion in architectural decisions. - Question 04
Are teams blocking each other?
No → Defer the split. Blocking happens at meaningful team scale; smaller teams rarely block themselves.Yes → Confirm the blocking is a release pattern, not a process pattern. Process problems are not solved with microservices. - Question 05
Are scaling issues real or hypothetical?
No → If hypothetical, do not split. Architecture for imaginary scale is one of the most reliable sources of expensive rework.Yes → Confirm with load data and a forecast. Real scale issues have numbers attached; imaginary ones have adjectives. - Question 06
Would customers notice the architectural change?
No → Be honest about the cost. Architecture invisible to customers is paid for by engineering time that customers do not value.Yes → Confirm the customer-facing improvement. If you cannot describe it, the split is paid in engineering currency for engineering benefit.
Common mistakes
Five common mistakes founders make
- 01
Copying enterprise architecture
Netflix, Amazon and Spotify operate at scales most startups will never reach. Copying their architecture imports the cost of their problems without inheriting their constraints. Pick the architecture that fits your stage, not the one that signals maturity.
- 02
Solving future problems
Architectural decisions for hypothetical scale tend to produce real complexity today against benefits that arrive in two years if at all. The cost of the wrong split is paid every sprint until it is undone.
- 03
Overengineering
Service meshes, event buses, distributed tracing, circuit breakers, every layer of microservice infrastructure is rewarding to build and expensive to operate. Add layers when forced, not by default.
- 04
Increasing operational burden
Each new service is a new monitoring target, a new deploy pipeline, a new on-call surface, a new dependency graph. Operational load grows non-linearly; small teams cannot carry it without sacrificing product velocity.
- 05
Mistaking complexity for maturity
A complex architecture looks impressive in interviews and on stage. It is not the same as a mature one. Mature engineering teams use the simplest architecture that works, and earn the right to complexity through real constraints.
Alternatives
Practical patterns that beat a premature split
Four patterns that get most of the benefit of microservices without the operational tax.
-
Modular monolith
One deployable, internally split into clearly-bounded modules with explicit interfaces. Gets most of the organisational benefits of microservices without the network calls, deployment overhead or distributed-system failures. The right default for almost every early-stage product.
-
Extract one service when forced
Identify the single component that has wildly different scaling, language or team boundaries, and extract just that one. Most companies stay at one or two extracted services for years; the third becomes a question, not a default.
-
Strangler pattern toward services
When the system genuinely outgrows the monolith, route traffic gradually to new services rather than rewriting. Reduces risk, preserves shipping velocity and lets the team learn microservice operations one service at a time.
-
Boring infrastructure choices
A monolith on a managed platform with a managed database, behind a CDN, with one background-worker process, runs further than founders expect. Boring infrastructure with disciplined code is the most underrated startup architecture.
Ronald's rule of thumb
Start with a monolith. Earn the complexity later.
Monoliths are easier to build, ship, debug and onboard into. They scale further than most founders expect. The right time to split is when the cost of not splitting becomes visible in shipping speed, scaling cost or team independence, not when an article suggested microservices are the future. Earn the split through evidence; do not assume it.
, Ronald · YourStartup.Expert
Summary
Summary
Microservices solve organisational and scaling problems most startups do not yet have. The six questions above separate real reasons to split from imagined ones. If you have fewer than ten developers, no real deployment bottleneck, no real team-blocking pattern and no real scaling crisis, the answer is almost certainly a monolith, well-structured, modular, deployed simply and changed quickly.
When a split is genuinely earned, extract one service at a time, use the strangler pattern, name the customer-facing benefit and budget for the operational overhead honestly. That discipline keeps architecture serving the business rather than satisfying the team's preference for new toys.
Common questions
Monolith or microservices, answered.
The questions founders ask before they commit to a system shape.
- Should startups use microservices?
- Almost never at the early stage. Microservices solve problems that appear at organisational scale: many teams that need to ship independently, services that genuinely require different scaling characteristics, ownership boundaries that require enforcement. Startups with small teams rarely have any of these problems, and adopting microservices imports the operational cost of the solution without the underlying need.
- When should I move away from a monolith?
- When the monolith is genuinely preventing the next stage of shipping or scaling, deployment bottlenecks, teams blocking each other, scaling problems with concrete numbers, or a service whose characteristics are wildly different from the rest of the system. If those conditions are missing, the monolith is fine; investing in code quality, modularity and disciplined ownership gives you most of what a microservice migration would, without the operational tax.
- Are microservices more scalable?
- They scale specific parts independently, which matters at high scale and rarely matters at low scale. A monolith on capable hosting with a sensibly designed database scales to tens of thousands of users, more than most startups ever reach. Microservices become 'more scalable' only when the cost of running each service smaller outweighs the cost of running the entire system uniformly. That trade rarely favours the early stage.
- Do microservices reduce development speed?
- Usually yes, at small team sizes. Each service comes with its own repo, deploy pipeline, monitoring, alerting, on-call rota and inter-service contracts. For small teams, that overhead is real and ongoing. Microservices improve speed when team coordination cost dominates, which only happens at meaningful org size. Below that threshold, monoliths almost always ship faster.
- How many developers justify microservices?
- A rough rule: start considering microservices around 20-30 engineers, and even then only when the coordination cost is visible in release behaviour. With fewer engineers, the modular monolith gives you almost all of the organisational benefit with none of the operational cost. The architectural decision should follow the org shape, not the other way around.