Engineering

Monolith First: Why We Don't Let Clients Build Microservices Until They Have 10,000 Users

Every founder wants microservices. Almost none of them need microservices yet. The hidden cost of premature distribution is one of the most reliable ways to kill a startup — and we've seen it happen four times in the last two years.

Intellis Idea22 October 20245 min read

In the last two years, we've been called in to help four Bangladeshi startups whose technology had become a liability. In three of the four cases, the root cause was the same: they'd built microservices too early.

The pattern: a smart CTO reads about Netflix's architecture. Gets excited about independent deployability, service autonomy, and technology diversity. Proposes a microservices architecture for a product that has 200 active users. The team agrees — it sounds sophisticated. Two years later, they have eight services, three teams who don't talk to each other, a distributed system that's hard to debug, and a feature delivery velocity that's slower than when they started.

What microservices actually cost

Microservices don't reduce complexity. They redistribute it — from code complexity to operational complexity. The benefits (independent scaling, independent deployment, technology choice per service) only become benefits when you have the user scale and team scale to justify the operational overhead.

Distributed tracing: you need this to debug anything cross-service. Setting it up correctly takes weeks.
Service discovery and load balancing: trivial in a monolith, non-trivial in a distributed system.
Data consistency: in a monolith, a database transaction is trivially consistent. Across services, maintaining consistency requires patterns (saga, outbox, eventual consistency) that are complex to implement correctly.
Local development environment: running 8 services locally for development is painful. Docker Compose helps, but it's never as simple as starting one process.
Testing across service boundaries: integration testing in a microservices architecture requires service mocks or a dedicated test environment. Both have costs.

The monolith's actual advantages

A well-structured monolith — with clear module boundaries, sensible dependency management, and separation of concerns — delivers most of the benefits teams cite for microservices, at a fraction of the operational cost.

Deployment is a single artifact. Debugging spans the full codebase with a single stack trace. Refactoring crosses module boundaries without requiring contract negotiations between service teams. Onboarding a new developer means understanding one codebase, not eight.

For a team of 5–15 engineers building a product with under 10,000 active users, the monolith is almost always the right choice. The time saved on operational complexity goes directly into feature development.

What 10,000 users has to do with it

Our rule of thumb — don't consider microservices until 10,000 active users — is deliberately provocative. It's a forcing function for a conversation about whether the team actually has a scaling problem.

At 10,000 active users, you typically have: real traffic patterns that reveal which parts of the system are under load, a team large enough to operate distributed systems, actual data on which features need independent scaling, and product stability that means your service boundaries are less likely to be wrong.

Before 10,000 users, your service boundaries are educated guesses. The thing that seems like it needs to scale independently at 1,000 users might look completely different at 50,000. The cost of wrong service boundaries in a microservices architecture is high — you've built operational infrastructure around the wrong abstraction.

The "modular monolith" is often the right answer at mid-scale: a single deployable with clearly separated modules that can be extracted into services if needed. Shopify ran a monolith to over $1 billion in revenue. Stack Overflow is largely a monolith. You are not Google.

How to structure a monolith for future extractability

If you want to keep your options open, structure your monolith in a way that makes extraction possible later without rearchitecting from scratch:

Module-based code organisation: one directory per domain (billing, users, products, orders). No cross-module imports at the model layer.
Explicit module interfaces: define what each module exposes to other modules. No reaching into another module's internals.
Domain events for cross-module communication: instead of direct function calls, publish events that other modules subscribe to. This is the pattern that makes extraction clean.
No shared database tables across module boundaries: each module owns its tables. Foreign keys that cross modules are a smell.

A monolith structured this way can be decomposed into services incrementally, one module at a time, when the business actually needs it. Most businesses find they never do.

Multi-Tenant Architecture for South Asian SaaS: The Decisions We Made and Why

Data residency, local payment gateways, Bengali language support, intermittent connectivity — building multi-tenant SaaS for South Asia is categorically different from building for the US market. Here's our architecture playbook.

Read article Engineering

Next.js vs Laravel in 2026: An Honest Breakdown for BD Startup CTOs

We've shipped production systems in both stacks — some at scale. This isn't a framework comparison article. It's a decision framework for the specific constraints BD startups face: hiring market, project types, long-term maintainability.

Read article

Work With Us

Let's build something that matters.

From ERP to HealthTech to custom SaaS — we partner with businesses that want software built properly.

Get in Touch More Articles

What microservices actually cost

Distributed tracing: you need this to debug anything cross-service. Setting it up correctly takes weeks.

Service discovery and load balancing: trivial in a monolith, non-trivial in a distributed system.

Data consistency: in a monolith, a database transaction is trivially consistent. Across services, maintaining consistency requires patterns (saga, outbox, eventual consistency) that are complex to implement correctly.

Local development environment: running 8 services locally for development is painful. Docker Compose helps, but it's never as simple as starting one process.

Testing across service boundaries: integration testing in a microservices architecture requires service mocks or a dedicated test environment. Both have costs.

The monolith's actual advantages

What 10,000 users has to do with it

How to structure a monolith for future extractability

If you want to keep your options open, structure your monolith in a way that makes extraction possible later without rearchitecting from scratch:

Module-based code organisation: one directory per domain (billing, users, products, orders). No cross-module imports at the model layer.

Explicit module interfaces: define what each module exposes to other modules. No reaching into another module's internals.

Domain events for cross-module communication: instead of direct function calls, publish events that other modules subscribe to. This is the pattern that makes extraction clean.

No shared database tables across module boundaries: each module owns its tables. Foreign keys that cross modules are a smell.

A monolith structured this way can be decomposed into services incrementally, one module at a time, when the business actually needs it. Most businesses find they never do.