Somewhere in a WeWork right now, a two-person startup with zero users is debating whether to use Kafka or RabbitMQ for their event bus. Their MVP does not exist yet, but their architecture diagram has 14 services, 3 message queues, and a service mesh. They will run out of money before they run out of infrastructure to configure.
This is the microservices trap, and it kills startups with alarming regularity.
The pattern repeats: a technical team reads about how Netflix, Spotify, or Uber decomposed their monoliths into microservices. They conclude that microservices are the "right" architecture. They build their MVP as microservices from day one. Six months later, they have spent 70% of their engineering time on infrastructure and 30% on the product. They have no users, no revenue, and an architecture designed for problems they do not have.
As Martin Fowler's seminal article on microservices makes clear, the pattern was designed for large organizations — not early-stage startups. Here is the uncomfortable truth: 90% of startups should start with a monolith. The other 10% should probably start with a monolith too.
Why Microservices Kill MVPs
The Complexity Tax
A monolith is one application, one deployment, one database, one set of logs. A microservices architecture with 5 services is:
- 5 separate codebases (or a monorepo with 5 deployment targets)
- 5 CI/CD pipelines to maintain
- 5 sets of environment variables
- 5 health checks and monitoring dashboards
- Inter-service communication (HTTP, gRPC, or message queues)
- Service discovery (DNS, load balancers, or a service mesh)
- Distributed tracing (because debugging across 5 services is impossible without it)
- Data consistency (because transactions across services require sagas or eventual consistency)
Each service adds operational overhead. For a team of 2–5 developers shipping an MVP, this overhead consumes 40–60% of available engineering hours. That is not a rounding error — it is the difference between launching in 8 weeks and launching in 8 months.
The Distributed Systems Tax
Microservices turn every function call into a network call. Network calls fail. They time out. They return stale data. They arrive out of order. Every interaction between services introduces failure modes that do not exist in a monolith.
In a monolith, a function call to calculate pricing takes microseconds and never fails (unless the whole process crashes). In microservices, the same calculation requires an HTTP request to the pricing service, which might be:
- Temporarily unavailable (deploy in progress)
- Slow (cold start, resource contention)
- Returning cached data from 5 minutes ago
- Returning an error because its database connection pool is exhausted
Now multiply this by every inter-service call in every user request. A single page load might touch 4–5 services, each with its own failure probability. Handling all these failure modes correctly — retries, circuit breakers, fallbacks, timeouts — is a full-time engineering discipline. Your MVP team does not have bandwidth for it.
The Testing Tax
Testing a monolith: start the application, run the tests. Testing microservices: start all services (or mock them), ensure they can communicate, run the tests, debug failures that are network issues masquerading as logic bugs.
Integration testing across microservices is an order of magnitude harder than testing a monolith. Contract testing, consumer-driven contracts, and end-to-end test environments add tooling and process that MVPs do not need. Our CI/CD pipeline guide covers testing strategies, and for MVPs, the answer is overwhelmingly: keep it simple with a monolith.
The Debugging Tax
User reports a bug: "I clicked submit and nothing happened." In a monolith, you check one log stream, find the error, fix it. In microservices, you check 5 log streams, correlate request IDs across services, discover that the payment service timed out waiting for the inventory service, which was waiting for the pricing service, which had a stale cache. Debugging takes 5x longer. Every bug becomes a distributed systems investigation.
The Monolith Advantage for MVPs
Speed of Iteration
A monolith lets you change anything in one commit. Rename a database column, update the API, fix the UI — all in one pull request, one review, one deploy. In microservices, the same change might touch 3 services and require coordinated deployments with backward compatibility.
During MVP development, you change everything constantly. Schema changes, API redesigns, feature pivots, UX overhauls — the entire product is in flux. A monolith accommodates flux. Microservices resist it. When building on an eight-week timeline, the ability to change direction in hours instead of days is existential.
Lower Cost
One application server costs less than five. One database costs less than five. One monitoring setup costs less than five. At the MVP stage, you are optimizing for runway — every dollar saved on infrastructure is a dollar available for product development and customer acquisition.
A typical monolith MVP on Vercel or Railway costs $20–50/month. The equivalent microservices architecture on AWS costs $200–500/month minimum, plus the engineering hours to manage it. Over a 6-month MVP phase, that is $1,000–$3,000 in unnecessary infrastructure costs — and 200+ engineering hours in unnecessary operational work.
Easier Debugging
One application, one log stream, one debugger. When something breaks, you set a breakpoint, step through the code, and find the issue. No distributed tracing. No cross-service correlation. No "which service owns this bug?" conversations.
Simpler Onboarding
A new developer joins your startup. With a monolith: clone the repo, run docker compose up or pnpm dev, start coding. With microservices: clone 5 repos, understand the service topology, configure inter-service communication locally, figure out which service to modify, and pray the local environment matches production.
Developer onboarding time with a monolith: hours. With microservices: days to weeks. For a startup hiring its first 3–5 engineers, this matters enormously.
When Microservices Actually Make Sense
Microservices are not wrong — they are wrong for MVPs. They make sense when:
1. You Have Proven Product-Market Fit
Once your product is stable and growing, decomposition becomes valuable. You know which components change frequently, which scale independently, and which have different reliability requirements. Decomposition decisions based on real usage patterns are sound. Decomposition decisions based on speculation are not.
Track your product-market fit metrics first. When retention curves flatten, revenue grows consistently, and feature requests outnumber architectural complaints — that is when microservices become a reasonable conversation.
2. Your Team Exceeds 10 Engineers
Microservices are an organizational pattern, not just a technical one. They exist to allow independent teams to deploy independently. If you have 3 developers, independent deployment is meaningless — you are all deploying the same thing. At 10+ engineers, service ownership enables parallel work without merge conflicts and deployment coordination.
Amazon's "two-pizza team" rule did not originate because microservices are technically superior. As Sam Newman explains in his work on building microservices, it originated because organizational independence requires service independence. No organization, no need for organizational patterns.
3. Components Need Independent Scaling
If your web application handles 100 requests/second but your data processing pipeline handles 10,000 events/second, running them in the same process wastes resources. Decompose when scaling requirements genuinely diverge — not when you imagine they might someday.
4. Different Components Need Different Technologies
If your web app is best built in TypeScript but your ML pipeline requires Python, separation is natural. Polyglot architectures are a legitimate reason for service boundaries. But if everything is TypeScript, the polyglot argument does not apply.
The Modular Monolith: Best of Both Worlds
The modular monolith is the architecture that most startups should adopt and almost none do. It combines the deployment simplicity of a monolith with the organizational clarity of microservices.
How it works:
- Single deployable application
- Internally organized into modules with clear boundaries
- Each module owns its domain logic, database tables, and API surface
- Modules communicate through well-defined interfaces, not direct database access
- Modules can be extracted into services later if needed
This is exactly the approach we use at Meld, grounded in Domain-Driven Design principles. The AeroCopilot aviation platform — one of the most complex SaaS products we have built — runs as a monorepo with 18 packages. Not 18 microservices. Not 18 deployment targets. Eighteen packages in a single deployable application with clear boundaries between domains.
Those 18 packages include:
- Database schema and migrations (Prisma)
- Authentication and authorization
- Flight planning domain logic
- Weather data processing
- Fuel calculation engine
- Regulatory compliance rules
- Notification system
- Content management
- Analytics and reporting
Each package has its own types, its own business logic, and its own test suite. They communicate through TypeScript interfaces, not HTTP calls. A function call between packages takes microseconds, not milliseconds. There are no network failures, no serialization overhead, no distributed transaction nightmares.
If AeroCopilot's weather processing eventually needs to scale independently — because it handles 100x more load than flight planning — extracting that package into a separate service is straightforward. The interface already exists. The boundary is already clean. The extraction is a deployment change, not an architecture change.
This is the key insight: design for modularity, deploy as a monolith. You get the organizational benefits of service boundaries without the operational cost of distributed systems. When you need to extract a service, the modular design makes extraction cheap. But you never pay the distributed systems tax until you actually need to.
Implementing a Modular Monolith
The practical steps:
Define bounded contexts. Identify the distinct business domains in your application. Each domain becomes a module. Use event storming to discover boundaries collaboratively.
Enforce module boundaries. Each module exposes a public API (TypeScript interfaces or a service layer). No module directly accesses another module's database tables or internal types. Lint rules and architecture tests enforce this.
Use a monorepo. Tools like Turborepo, Nx, or pnpm workspaces manage multi-package monorepos. Each module is a package with its own
package.json, its own tests, and its own build configuration. Our monorepo architecture guide covers the setup.Share through interfaces, not implementations. The flight planning module does not import the weather module's database queries. It imports a
WeatherServiceinterface and callsgetWeatherForRoute(). The implementation details are hidden.Test at the boundary. Each module has unit tests for its internal logic and integration tests for its public API. If the integration tests pass, the module is working correctly regardless of internal changes.
The Migration Path
Starting with a monolith does not lock you into a monolith forever. The migration path is well-understood:
- Phase 1 (MVP): Monolith. Ship fast, iterate constantly, find product-market fit.
- Phase 2 (Growth): Modular monolith. Refactor into clear modules with enforced boundaries. This is where most companies should stay permanently.
- Phase 3 (Scale): Selective extraction. Extract specific modules into services when — and only when — you have concrete evidence that they need independent scaling, deployment, or technology.
Most successful companies never reach Phase 3. Shopify runs a modular monolith that handles billions in transactions. GitHub ran a monolith for over a decade. Basecamp has been a monolith since 2004 and serves millions of users. Stack Overflow famously runs on a handful of servers with a monolithic architecture.
The companies that do reach Phase 3 — Netflix, Amazon, Uber — did so after years of monolithic growth, with hundreds of engineers and concrete scaling bottlenecks. They did not start with microservices. They earned the need for them.
The Decision Framework
Ask yourself three questions:
- Do you have product-market fit? No → Monolith. Yes → Maybe modular monolith.
- Do you have 10+ engineers? No → Monolith. Yes → Modular monolith, consider selective extraction.
- Do you have concrete, measured scaling bottlenecks? No → Do not add services. Yes → Extract the specific bottleneck.
If you answered "No" to all three, you do not need microservices. You need to ship your product, find customers, and prove your business model. Architecture decisions made without users are speculation. Speculation with infrastructure costs is waste.
Stop over-engineering. Start shipping.