Microservices vs Monolith for SaaS in 2026: What to Choose?

The short answer: Start with a monolith. Most SaaS products never need microservices. The ones that do should extract services only when the problem they solve is clear and concrete — not in anticipation of scale you don't have.

This is a controversial opinion in some engineering circles. Here's why we hold it.

What each architecture actually is

Monolith: All application code — API handlers, business logic, database access — runs in a single deployable unit. One server process, one deployment, one codebase (though potentially multiple modules within it).

Microservices: The application is split into multiple independent services, each responsible for a specific business capability. Each service deploys independently, scales independently, and often has its own database.

The key word is independent. If your "microservices" must all deploy together to function, you've built a distributed monolith — which combines the complexity of microservices with none of the benefits.

The case for starting with a monolith

You don't know your service boundaries yet. Service boundaries in microservices must align with your business domains. Early in a product's life, you don't know where those boundaries are — you're still learning what the product is. A monolith lets you refactor boundaries freely within a single codebase. Refactoring across service boundaries in a microservices architecture is orders of magnitude more painful.

Operational complexity compounds quickly. Each microservice needs its own CI/CD pipeline, deployment configuration, logging, monitoring, and network security. For a team of 3–5 engineers, the overhead of managing 8–12 services consumes the engineering time that should go into building product.

Debugging across services is hard. Tracing a bug that starts in the API gateway, passes through the user service, triggers an event processed by the notification service, and fails in the email service is genuinely difficult. In a monolith, the stack trace tells you exactly what happened.

The successful companies were monoliths first. Shopify, GitHub, Basecamp, and Stack Overflow ran on monoliths at massive scale. Shopify famously optimised their monolith rather than breaking it up. The move to microservices is a scaling strategy for specific problems — not a prerequisite for success.

The case for microservices (when it genuinely applies)

Microservices make sense when you have concrete, specific problems that they solve:

Independent scaling requirements: Your video processing service needs 10x more compute than your API during uploads. In a monolith, you scale everything. With microservices, you scale only what needs it.

Different deployment cycles: Your data pipeline deploys multiple times per day. Your core API deploys weekly. Coupling them means frequent full deployments or managing complex feature flags.

Technology requirements: One part of your system genuinely benefits from a different language, runtime, or technology stack. (Rare, and often overstated.)

Organisational scale: Conway's Law — your architecture mirrors your org structure. When you have 50+ engineers in independent teams, service boundaries let teams ship independently without stepping on each other.

If none of these apply to you, microservices add complexity without benefit.

The modular monolith — the practical middle ground

The architecture that avoids both problems: a modular monolith with clear internal boundaries.

One deployable unit, but with the codebase organised into modules (users, billing, projects, notifications) with explicit interfaces between them. Each module has its own directory, its own types, and a defined API for how other modules interact with it.

When — if ever — you need to extract a service, the module is already defined. The extraction is mechanical, not architectural.

src/
  modules/
    users/          ← owns user data and auth
      api/
      services/
      repository/
    billing/         ← owns Stripe integration and subscriptions
      api/
      services/
      repository/
    projects/        ← core product feature
      api/
      services/
      repository/
    notifications/   ← email, in-app notifications
      api/
      services/

This is how Basecamp, Hey, and many successful SaaS products structure their code at scale.

When SaaS products should actually consider microservices

Your team is 20+ engineers split across product areas
You have a specific service with 10x different scaling requirements
You need to rebuild a specific component in a different technology without affecting the rest
Your deployment complexity has genuinely become a bottleneck

If you're an early-stage SaaS with under $1M ARR: build a well-structured monolith. Extract services later if specific problems demand it.

Talk to us about SaaS architecture →