Microservices will not save your early-stage product. A monolith usually will
· 6 min read · Mona Technologies
Microservices solve a real problem: they let large teams deploy independently without stepping on each other, and they let a company scale one bottlenecked component without scaling everything else. Almost none of that applies to a five-person team building a product that might pivot twice before it finds a market.
What microservices actually cost early
- Distributed debugging — a bug that spans three services takes longer to trace than one that spans three functions in the same process
- Network calls where function calls used to be, adding latency and a whole new category of failure (timeouts, retries, partial failures)
- Deployment infrastructure — service discovery, API gateways and inter-service auth need to exist before the first service does
- Data consistency across services, which usually means learning eventual consistency and distributed transactions under deadline pressure
The monolith case
A well-structured monolith — modular internally, with clean boundaries between domains even though it deploys as one unit — gives a small team almost everything they actually need: one codebase to reason about, one deployment pipeline, and refactoring that's a file move instead of a cross-service migration. When the product changes direction, which it will, changing a module inside a monolith is far cheaper than renegotiating a contract between two services.
“Almost every successful microservice story I have heard also involved a painful migration from a monolith that started out as the right choice and was outgrown, not a system that was microservices from day one.”
When microservices genuinely earn their cost
- You have multiple teams that need to deploy independently without coordinating releases
- One component has wildly different scaling needs than the rest — a video transcoding job versus a CRUD API
- You need to isolate a component for compliance reasons (e.g., PCI scope for payment processing)
- The organization, not just the codebase, is already structured around separate domains with separate owners
The practical middle path
Build the monolith with domain boundaries respected internally from the start — separate modules for billing, auth, and core product logic, communicating through clean interfaces even inside one process. That structure is what actually makes a later split into services cheap, if and when the scaling need is real. Splitting prematurely, before the boundaries are proven by real usage, tends to produce services that need to be merged back together within a year — which is a harder migration than the one you were trying to avoid.