• Softwares

Kannan Rajendiran

September 18, 2026

.

4 Min read

Microservices have dominated architecture conversations for years, to the point where choosing a monolith can feel like admitting you’re behind the times. In practice, the right choice depends far more on team size, deployment maturity, and actual scaling needs than on which approach is currently more discussed in engineering blogs.

Core Trade-offs at a Glance

Why Most Startups Should Start With a Monolith

A small team building a new product benefits enormously from a monolith’s simplicity: one codebase, one deployment pipeline, one place to debug an issue end to end. Microservices introduce real operational overhead, service discovery, inter-service communication, distributed tracing, that a small team has to build and maintain on top of actually building the product. For most early-stage products, this overhead outweighs the theoretical scaling benefits microservices offer, benefits that rarely matter until the product has found real traction.

Signs Your Team Has Outgrown a Monolith

• Deployment friction: a full monolith deployment for a small change to one feature is slowing the team down noticeably.
• Team coordination bottlenecks: multiple teams working in the same codebase are frequently blocking each other on merges and releases.
• Uneven scaling needs: one part of the application (checkout, for example) needs to scale far more aggressively than the rest.
• Codebase complexity: the monolith has grown large enough that onboarding new engineers takes noticeably longer than it should.

The Middle Ground: Modular Monoliths

Between a fully coupled monolith and full microservices sits a modular monolith, a single deployable application internally organised into well-defined, loosely coupled modules with clear boundaries. This approach captures much of the organisational clarity microservices offer, defined ownership boundaries, clearer code organisation, without the operational overhead of running and coordinating multiple independently deployed services. Many teams find this middle ground genuinely sufficient for years before, if ever, needing to split into true microservices.

Cost of Getting It Wrong in Either Direction

The third failure mode, poorly designed microservice boundaries, is arguably the worst outcome, since it combines the downsides of both approaches. Services that are too tightly coupled through shared databases or excessive synchronous calls end up requiring coordinated deployments anyway, defeating the purpose of splitting them apart in the first place.

A Practical Decision Framework

For a new product with a small team, default to a monolith, ideally organised in a modular way from the start to ease a future transition if it becomes necessary. Revisit the decision specifically when deployment friction, team coordination bottlenecks, or clearly uneven scaling needs become a measurable, recurring problem, not simply because microservices are the more discussed architecture pattern. Askan’s software architecture consulting work with growing teams consistently finds that the right time to split a monolith is driven by these specific pain points, not by a fixed team size or revenue milestone.

Further Reading

For a broader technical comparison of these architectural patterns and their historical development, the Wikipedia entry on microservices provides useful background on how this architectural style evolved and the specific problems it was designed to solve, context that helps clarify when those original problems actually apply to your own situation.