Start With a Monolith. Seriously.

Forty-two percent of companies moved back to monoliths or modular monoliths in 2026, according to industry surveys tracking architectural decisions. Not because microservices failed as a concept — but because teams adopted them before they had the problems microservices solve. The architecture was right. The timing was wrong. And the cost of that mismatch is measured in years of unnecessary complexity.

The consensus in 2026 is more pragmatic than it was even two years ago, partly because of high-profile public postmortems from companies that decomposed too early, and partly because the tooling landscape has changed the tradeoffs entirely.

The complexity you don't need yet

A monolith has no API contracts between services. No network latency between components. No distributed transaction complexity. No service discovery infrastructure. For a founding team that needs to go from idea to working product in 90 days, that simplicity isn't a limitation — it's a structural advantage.

Deployment speed tells the story clearly: monolith deployment is 3x faster than distributed services for small teams. When your entire application ships as a single artifact, there's one CI pipeline, one deployment target, and one thing to debug at 2 AM when something breaks. The real cost of self-hosting is already dominated by operations — adding service mesh complexity to that equation before you need it is choosing to make your most expensive line item more expensive.

The recommendation is straightforward: if your team has fewer than 20 engineers, start with a monolith. Not because monoliths are always better — because microservices solve problems you don't have yet, and they create problems you don't need.

The modular monolith is the real answer

The false binary of "monolith versus microservices" has done more damage than either architecture alone. The answer for most growing teams is the modular monolith: a single deployable application with clearly defined internal boundaries.

A modular monolith uses the same separation-of-concerns principles as microservices — distinct modules for distinct capabilities, clean interfaces between them, independent data ownership where possible — without the operational overhead of distributed systems. Technology fragmentation becomes a design decision rather than an accident.

The recommended progression that multiple architecture guides converge on: start with a monolith for teams of 0-15 engineers, build a modular monolith as domains clarify, and move to microservices only when specific pain points — team size above 50, dramatically different scaling requirements, or regulatory isolation needs — demand it.

Your infrastructure environment shapes what's viable, and for most businesses under $50M ARR, the viable answer is simpler than the conference talks suggest.

When to decompose (and how)

The Strangler Fig pattern — named after the tropical trees that gradually envelop and replace their hosts — is the recommended approach for teams that outgrow their monolith. New capabilities are built as standalone services. Existing functionality is extracted incrementally over 12 to 18 months. There is no "big bang" rewrite.

The triggers for decomposition are specific and measurable: different parts of your system need dramatically different scaling (your API handles 10x the traffic of your admin panel), independent teams need to deploy independently without coordinating releases, or regulatory requirements demand physical isolation of certain data processing.

Notice what's not on that list: "our architecture looks outdated." That's not a trigger. That's the bandwagon effect. Security architecture comes first, and a well-secured monolith is infinitely better than a poorly-secured collection of microservices with inconsistent authentication.

AI changed the equation (but not the way you'd expect)

AI coding assistants — GitHub Copilot, Cursor, and their successors — perform measurably better within a single, well-scoped service with clear interface contracts than when navigating a large monolith with implicit dependencies. This is a new argument for service decomposition that didn't exist three years ago.

But it's an argument for modular monoliths, not microservices. Clean module boundaries within a single application give AI assistants the scoped context they work best with, without the distributed systems overhead. The tool you haven't built might be a better module boundary, not a new service.

Korn Ferry projects a global shortage of 85 million skilled technology workers by 2030. When talent is scarce, the architecture that requires the fewest specialized operators wins. A monolith that one person can deploy beats a microservices architecture that needs a platform team to maintain. The real tradeoffs are always about operational capacity, not theoretical elegance.

Related reading

• What Self-Hosting Actually Costs (It's Not What the Blog Posts Say)
• Self-Hosted vs. Cloud: The Real Tradeoffs
• The Technology Fragmentation Problem Most Businesses Don't See
• Your Infrastructure Environment Shapes What's Viable

Frequently Asked Questions

When should a startup use microservices instead of a monolith?

When you have more than 50 engineers who need to deploy independently, when different parts of your system have dramatically different scaling needs, or when regulatory requirements demand physical isolation of certain workloads. If none of those conditions apply — and for most businesses under $50M ARR they don't — a modular monolith gives you the same design benefits without the operational complexity.

What is a modular monolith?

A single deployable application with clearly defined internal module boundaries. Each module owns its domain logic and data, communicates with other modules through defined interfaces, and can be extracted into a standalone service later if needed. It combines the deployment simplicity of a monolith with the organizational clarity of microservices.

How do you migrate from a monolith to microservices without a risky rewrite?

The Strangler Fig pattern: build new capabilities as standalone services, extract existing functionality incrementally over 12-18 months, and route traffic gradually from the monolith to the new services. Never attempt a "big bang" rewrite — it takes years, costs millions, and has a high failure rate. Incremental migration preserves business continuity while progressively realizing the benefits of decomposition.

Do AI coding tools favor monoliths or microservices?

They favor well-scoped contexts — which means modular monoliths and small, focused microservices both work well. Large monoliths with implicit dependencies and tangled module boundaries are harder for AI assistants to navigate. The practical takeaway: clean architecture matters more than the deployment model. If AI can understand your module boundaries, it can help regardless of whether those modules deploy together or separately.