Startup

Why We Stopped Using Microservices for New Projects Under $5M ARR

After 18 months helping a client untangle premature microservices, here is what we learned about when distribution is a liability, not an architectural advantage.

admin · February 11, 2026 · 1 min read

The Project

A SaaS platform built from day one as 14 microservices. 8 engineers, 400 customers, $1.8M ARR. A single feature touching user permissions required changes across 4 services, 4 pull requests, and careful deployment ordering. On-call was a sustained nightmare.

The Hidden Costs

  • Network calls between services that would be simple function calls in a monolith
  • Distributed transactions requiring saga orchestration or two-phase commit
  • Multiple deployment pipelines, test environments, and monitoring dashboards to maintain
  • Engineers needing to understand the full service graph to debug any single issue

What We Did Instead

We migrated to a well-structured modular monolith with strict internal module boundaries enforced by tooling. Deployment became a single pipeline. On-call became comprehensible. Feature velocity increased measurably within the first sprint.

Our Default Now

Start with a modular monolith. Extract services only when you have a specific, measurable justification: a workload requiring independent scaling, a compliance boundary requiring process isolation, or a team large enough that service ownership meaningfully reduces coordination cost. For most products under $5M ARR with fewer than 15 engineers, that day has not arrived yet.