Every few years, the software industry finds a new architectural trend and treats it as the answer to every problem.
Over the last decade, that trend has been microservices.
Many developers now assume that if you're building a modern application, you should start with:
- Microservices
- Kubernetes
- Event-driven architecture
- Service mesh
- Distributed tracing
But here's the uncomfortable question:
Do most startups actually need any of that?
In my opinion, most don't.
The Influence of Big Tech
Much of the industry's enthusiasm for microservices comes from companies like Netflix, Amazon, Uber, and Spotify.
These companies operate at a scale that most businesses will never reach.
They have:
- Hundreds or thousands of engineers
- Multiple product teams
- Massive infrastructure
- Millions of users
- Continuous deployments
For them, microservices solve real organizational and technical challenges.
The problem starts when smaller teams adopt the same architecture without having the same problems.
Complexity Is Not Free
Microservices are often sold as a scalability solution.
What is rarely discussed is the complexity they introduce.
A feature that once required a simple function call now involves:
- Network communication
- API contracts
- Authentication
- Timeouts
- Retries
- Monitoring
- Distributed tracing
- Failure handling
Complexity doesn't disappear.
It simply moves from application code into infrastructure.
And infrastructure complexity can become expensive very quickly.
The Distributed Monolith Problem
One of the most common mistakes I see is the creation of a distributed monolith.
The architecture looks modern.
There are dozens of services.
There are multiple repositories.
There are APIs everywhere.
But every service depends on every other service.
Deployments must be coordinated.
Changes ripple across the entire system.
Failures become harder to diagnose.
The team inherits the operational burden of microservices without gaining the independence they were supposed to provide.
Why Monoliths Still Make Sense
The word "monolith" often gets treated as if it's automatically a bad thing.
It isn't.
A poorly designed monolith is problematic.
A well-designed monolith can be incredibly effective.
Benefits include:
Faster Development
Developers spend more time shipping features and less time managing service boundaries.
Easier Debugging
A single codebase is easier to understand than twenty interconnected services.
Simpler Deployments
One deployment pipeline is often easier to maintain than dozens.
Lower Operational Costs
Less infrastructure usually means less maintenance and lower cloud bills.
For startups, these advantages are often more valuable than the theoretical scalability benefits of microservices.
When Microservices Actually Make Sense
Microservices become valuable when:
- Multiple teams need independent deployments
- Different parts of the system scale differently
- Team ownership boundaries become important
- The monolith is actively slowing business growth
Notice what isn't on this list:
"Because everyone else is doing it."
Build for Today's Problems
One of the most expensive mistakes in software engineering is solving problems that don't exist yet.
Many startups spend months preparing for scale they may never reach.
Meanwhile, competitors with simpler architectures are shipping features faster, gathering feedback sooner, and iterating more effectively.
The goal of architecture is not to impress other engineers.
The goal is to solve business problems with the least amount of unnecessary complexity.
Sometimes that means microservices.
More often than many teams would like to admit, it means starting with a monolith.
And that's perfectly fine.
Discussion
If you were launching a new SaaS product today with a team of 5–10 engineers:
Would you start with a Monolith or Microservices?
Why?
I'd love to hear your thoughts in the comments.
Top comments (0)