B2B SaaS scaling: $1M to $10M ARR engineering choices

The engineering choices that get a B2B SaaS to $1M ARR are mostly the right ones for that stage. Ship fast, prefer monolithic over distributed, optimise for iteration speed, ignore architectural purity. Founders who do this win their first 100 customers, often with a small team and limited capital.

The same choices, unchanged, are what stalls the company at $3M–$5M ARR. The patterns that scaled well to 100 customers fail in particular ways at 1,000 customers, and the company spends 18 months refactoring under load instead of selling. The choices to make differently are knowable in advance.

This post is the architectural delta between the $1M-ARR shape and the $10M-ARR shape, written for technical founders and CTOs.

What changes between $1M and $10M

Three structural shifts:

1. Customer concentration. At $1M ARR, you might have 50–200 customers. Lose any one and revenue dips. At $10M ARR, you might have 200–800 customers. Lose any one and it’s a footnote. The system has to support customer-specific quirks at scale, not as one-off accommodations.
2. Per-customer data volume. At $1M ARR, the largest customer’s data fits in a single database. At $10M ARR, the largest customer might be 100× larger than the median. Schema decisions that worked uniformly start failing at the tail.
3. Operational surface. At $1M ARR, the team can fix everything by hand. At $10M ARR, the team can’t. Operational tooling becomes load-bearing.

The architectural choices that handle all three are what separate companies that ship the next 9× from companies that stall.

The five choices that matter most

1. Tenant isolation model.

At $1M ARR you probably have tenant_id everywhere. This works to maybe $3M–$5M ARR. By $10M, the per-tenant data variance and the per-tenant operational requirements (customer-specific data exports, deletions, encryption keys) make schema-per-tenant or shard-per-tenant models more sustainable. Migration is painful but tractable; staying on tenant_id past the inflection point is more painful.

2. Background job infrastructure.

At $1M ARR a single Sidekiq / Celery / SQS-Lambda is fine. By $10M ARR, you need queue isolation between workloads (a slow report shouldn’t block transactional jobs), per-tenant queue quotas (one customer shouldn’t drown out others), and per-job observability (when a job fails at 3am, you need traces). Build this before you need it.

3. Schema migration discipline.

At $1M ARR you can run a destructive migration during off-hours. By $10M ARR, you can’t — there’s no off-hours, and migrations on large tables take hours. Online migration tools (gh-ost, pt-online-schema-change, or expand/contract patterns natively) become non-negotiable.

4. Observability stack.

At $1M ARR, tail logs and grep. By $5M ARR, you need traces (OpenTelemetry), metrics (Prometheus or equivalent), and structured logs in a queryable backend. By $10M, you need alerting that distinguishes real incidents from noise. Build this before the first major outage, not after.

5. Customer-facing API contract management.

At $1M ARR, breaking changes to the API are an internal coordination cost. By $10M, breaking changes are a customer-facing announcement. You need versioned APIs, deprecation calendars, and a contract-first development discipline that prevents accidental breaks.

The choices that don’t matter as much as people think

Three architectural debates that consume disproportionate energy without proportional impact:

1. Microservices vs monolith. A well-organised monolith scales to $50M ARR. The microservices conversation is usually premature. Wait until the team is large enough that coordination cost on the monolith genuinely exceeds the operational cost of microservices — usually 30+ engineers.
2. Programming language choice. The language you started with is almost always fine. Rewrites in a different language are expensive and rarely produce business outcomes the original language couldn’t have. Rewrite when there is a specific, measurable reason — not because the new language is fashionable.
3. Database choice. PostgreSQL handles almost every B2B SaaS workload to $50M+ ARR. The “we need MongoDB / Cassandra / DynamoDB” conversations are usually solving problems that PostgreSQL would have solved fine.

Spending engineering time on these debates is opportunity cost. Spending it on the five above is leverage.

Where the team shape needs to change

The team that gets you to $1M ARR (3–5 generalists) is not the team that gets you to $10M (15–25 with specialisations). Three structural transitions:

1. Specialised SRE / platform function. Around $3M ARR, the operational surface starts requiring dedicated owners. A generalist team trying to also operate the platform is a team that ships less.
2. Dedicated frontend and backend tracks. Around $5M ARR, the depth of expertise required in each layer outstrips what a generalist can maintain. Specialisations become valuable.
3. A first hire in security / compliance. Around $5M–$10M ARR, the customer security questionnaires become unmanageable as a side-of-desk task. A dedicated owner pays for themselves in won deals.

Plan these hires 6–9 months ahead of the inflection.

What we ship for B2B SaaS at this stage

Two engagement shapes are common:

1. Strategy engagement (4 weeks, fixed price): a written brief on the architectural delta between the current state and the $10M-ARR shape, with prioritised refactor recommendations.
2. Build engagement (12–24 weeks, fixed price per scope): execution on one or two of the five choices above, typically the tenant isolation refactor or the observability stack.

We do not take on full re-platforming engagements at this scale. The right team to operate the post-refactor system is the in-house team. Our role is to ship the architectural pieces they don’t have time to build under the load of selling.

---

Read more: /sectors/b2b-saas · /strategy/ · /build/