# From Concept to $10M ARR: The SaaS Architecture Decisions That Matter
I've helped launch 50+ SaaS platforms. The ones that hit $10M ARR share something in common: they made specific architectural decisions in the first 90 days that enabled scale. The ones that stalled usually made different decisions.
This is about the architecture decisions that matter and the ones that don't.
The Architecture Decisions That Define Your Ceiling
1. Monolith vs. Microservices (Decision: Monolith for first $5M, then fragment)
Conventional wisdom: Microservices scale better. Reality: Monoliths let you ship faster in years 1-2, which matters more.
Why monolith wins (year 0-2): - Single codebase = faster feature velocity - Easier debugging (no distributed systems debugging) - Simpler deployment (one Docker container) - Lower operational overhead (one database, one cache)
When to fragment: When a single monolith service hits 80%+ CPU on deployed containers, you're at the scale inflection. That's usually $2-5M ARR.
Specific decision: Build as a monolith. Your goal isn't elegance; it's $10M ARR.
2. Database Structure (Decision: PostgreSQL + Redis, structured from day 1)
Don't start with schema-less databases (MongoDB) to "avoid schema planning." You will regret it.
The right stack (year 0-5): - Transactional data → PostgreSQL (ACID guarantees) - Cache layer → Redis (sub-100ms lookups) - Search → Elasticsearch (optional; Postgres FTS is sufficient for 5M ARR) - Analytics → Snowflake or BigQuery (separate, query-only)
Why: PostgreSQL forces you to think clearly about data structure. That clarity compounds over 4 years.
Specific practices: - Design your schema for the queries you'll need (not the relationships) - Implement migrations as code (Alembic/Flyway) - Separate write database (transactional) from read database (analytics) at scale
3. API Design (Decision: RESTful + GraphQL hybrid, strongly typed from day 1)
REST vs. GraphQL? Both. - Use REST for simple CRUD operations (80% of your API) - Use GraphQL for complex multi-resource queries (dashboard, analytics)
Strong typing (mandatory): - Define API contracts with OpenAPI / GraphQL schema - Generate client libraries automatically (don't hand-code) - Never accept an API change that breaks the contract
Specific decision: Use TypeScript/Zod on both frontend and backend. Type safety at the API boundary prevents 50% of production bugs.
4. Authentication & Authorization (Decision: OAuth2 + Role-Based Access Control from day 1)
Don't start with "we'll add SSO later." You won't.
Day 1 architecture: - OAuth2 provider (Auth0, Okta, or custom) - Role-Based Access Control (RBAC) hardcoded into the permission model - Resource-level checks (not just feature-level)
Why day 1 matters: Enterprise customers will demand SCIM and SAML. If you build auth on top of a weak foundation, you'll rewrite it.
5. Logging & Observability (Decision: Structured logging + observability platform from day 1)
Console.log() is not observability.
Required from day 1: - Structured logging (JSON, not strings) - Distributed tracing (every request has a trace ID) - Metrics (latency, error rate, business metrics) - Alerting (page-on-call for errors)
Why day 1 matters: If you ship 4 years of random logging, you can't retrofit observability. You'll be blind.
Specific tech: - Logging: Cloud Logging (GCP), CloudWatch (AWS), or Datadog - Tracing: Jaeger or Datadog APM - Metrics: Prometheus + Grafana or Datadog
The Infrastructure Decisions
Deployment (Decision: Kubernetes after $2M ARR, not before)
Year 0-2: Use managed services (Cloud Run, Lambda, App Engine) - Pros: Zero ops overhead, scales automatically, cheap initially - Cons: Vendor lock-in, eventual cost increase as you scale
Year 2-4: Migrate to Kubernetes - Pros: Cost-effective at scale, vendor-agnostic, powerful scaling - Cons: Operational complexity
Specific decision: Don't Kubernetes prematurely. But also don't be so dependent on AWS Lambda that migration is difficult when you hit scale.
Data Pipeline (Decision: Event-driven architecture, but don't demand event-sourcing)
As your SaaS scales, you'll need: - Real-time analytics (dashboard data) - Asynchronous processing (email, webhooks, batch jobs) - Event streaming (audit logs, compliance)
Architecture: - Transactional database (PostgreSQL) is source of truth - Change Data Capture (CDC) streams changes to event queue (Kafka, Pub/Sub, SQS) - Separate read-optimized stores (Snowflake for analytics, Elasticsearch for search)
Don't do: Event sourcing is overkill for 90% of SaaS products. Stick with CDC + CQRS pattern.
The Operational Decisions
Deployment Strategy (Decision: Blue-Green only; no Canary until $5M ARR)
Blue-green deployment: 1. Run two identical environments (blue = current, green = new) 2. Deploy to green 3. Run integration tests 4. Switch traffic from blue to green 5. Old blue becomes new green
Why blue-green matters: - Instant rollback (switch back to blue) - No complex traffic splitting - Works with all infrastructure
When to upgrade to canary deployment: When you have enough traffic to detect performance differences.
Testing (Decision: Integration tests matter more than unit tests)
Investment priority: 1. Integration tests (60% - test the actual system) 2. Unit tests (30% - test critical business logic) 3. E2E tests (10% - expensive, pick critical flows only)
Specific practice: Mock external services, but test your code against a real database and real cache.
The Scaling Journey
$0-1M ARR - Monolith - Single PostgreSQL - Redis cache - Simple observability - Manual deployment
$1-5M ARR - Monolith (possibly starting to split core services) - PostgreSQL + read replica - Redis cluster - Advanced observability + alerting - CD/CI pipeline (not manual)
$5-10M ARR - Microservices (auth, payments, core business logic) - PostgreSQL (multi-region if needed) - Distributed cache (Redis cluster) - Event-driven architecture (Kafka for async) - Comprehensive observability + on-call testing
$10M+ ARR - Full microservices + event-driven - Multi-region deployment - Advanced caching strategies - Real-time analytics infrastructure - Dedicated platform engineering team
The Mistakes We See Most Often
1. Premature optimization — Building for scale you don't have yet 2. Over-engineered auth — Enterprise-grade OAuth2 on day 1 (overkill initially) 3. No observability — Shipping without structured logging and metrics 4. Vendor lock-in — AWS-specific architecture that's impossible to migrate 5. Inadequate testing — Skipping integration tests to save time initially
The Architecture Anti-Patterns
❌ Don't: Start with Kubernetes (use managed services) ❌ Don't: Use MongoDB for transactional data ❌ Don't: Build your own authentication (use OAuth2) ❌ Don't: Ship without observability ❌ Don't: Optimize for scale at $100k ARR (optimize for feature velocity)
The Decisions That Actually Define Your Ceiling
1. Strong typing — Saves 50% of bugs 2. Structured logging — Enables debugging in production 3. API contracts — Enables parallel client/server development 4. Monolith — Enables feature velocity in years 0-2 5. Operational discipline — Enables reliability and scaling
These five decisions will get you to $10M ARR. The infrastructure decisions (Kubernetes, microservices, event sourcing) matter less than you think if the foundations above are solid.
Build for clarity and velocity in years 0-2. Optimize for scale in years 2+.