Monolith vs Microservices: The Right Question Is When

A four-person team chose microservices from day one. Sixty percent of their engineering time went to infrastructure. They shipped almost no product. Microservices aren't wrong — they're just wrong for most early-stage teams.

Here's how to think about it. Start with your team size. Under five engineers? A monolith isn't a compromise — it's the correct call. You don't have the operational bandwidth for distributed systems. Between five and twenty, and traffic is growing, a modular monolith gives you clean boundaries without the overhead. Only once you're past that — real scale, real team depth — do microservices actually earn their cost. The architecture should match the stage. Not the other way around.

The burden difference is real. A monolith at early stage: one deployment pipeline, one codebase, full-team context. Microservices at early stage: service discovery, distributed tracing, per-service CI/CD, inter-service contracts. That's infrastructure work that doesn't ship features. The right architecture is the one that gets out of your team's way. At your current scale, that's almost always simpler than you think.