Skip to content
CloudNativeApplication.com

Sample 01 • Stack Recommendation • 13 min

Best Cloud-Native Stack for a New Production SaaS

You have 5 engineers, a multi-tenant SaaS, and you need to ship secure, observable, and scalable software without building a platform team by accident. This is the default we’d recommend — and exactly when to change it.

Audience: Platform / founding engineers, CTOsUpdated 2026-08-27Decision-first, not encyclopedia
How to use this: Treat the “Default” column as your ADR starting point. Check “Swap when…” for your constraints (team, scale, data, compliance). If none apply, ship the default.

The defaults (why we picked them)

Defaults are chosen for team-size leverage: maximum production capability per engineer. They are boring on purpose, well-understood, cheap to operate, and easy to hire for. We bias toward managed services early so your 5 engineers ship product, not platform.

LayerDefault pickWhySwap when…
ComputeManaged container platform (Cloud Run / ECS Fargate / App Service)Zero k8s ops; scales to ~500 RPS/service without dedicated platform timeNeed multi-cloud portability, custom operators, or >15 services with tight control → consider Kubernetes
DBManaged Postgres (RDS / Cloud SQL / Neon / Supabase)Strongest ecosystem, hiring pool, extensions, lowest surprise factorGlobal low-latency writes or true multi-region active-active → CockroachDB; extreme scale with loose consistency → consider DynamoDB/Spanner
Cache / JobsRedis (managed) + BullMQ / Sidekiq / Cloud TasksSimple, proven, visible failure modesThroughput >50k msgs/s or replay/retention needs → Kafka; cheap serverless jobs only → Cloud Tasks / SQS
Object storageS3 / GCS / R2Durability + price; future-proofS3 egress cost dominates → R2 / Cloudflare
IaCTerraform + small modulesPortable, well-known, code-reviewableCloud-native only + small team → Pulumi (TS) or SST is fine; avoid CDK for tiny teams (overkill)
CI/CDGitHub ActionsWhere code already lives; fastest pathHeavy compliance + complex pipelines → GitLab or Buildkite
ObservabilityOTel → Grafana Cloud (Loki + Mimir + Tempo) or DatadogOne standard to instrument; pick vendor vs OSS on MTTR vs budgetTeam ≤6 and need fast MTTR → Datadog/Honeycomb; cost-sensitive with >30d retention → Grafana stack
AuthClerk / Auth0 / WorkOS (for B2B SSO)Auth is not your product; don’t build itNeed HIPAA-grade audit + passkeys → WorkOS / Stytch

Reference architecture (kept intentionally narrow)

Browser → CDN (Cloudflare) → Managed containers (3–5 services max) → Postgres (managed) + Redis → Object storage + managed queue. Everything behind one VPC, least privilege IAM, and OTel from day one.

  • One monolith or 3–5 services — not “microservices.” Service boundaries only when deploy cadence or failure domain diverges.
  • Async only where needed: email, webhooks, billing, video processing. Don’t add Kafka for “future scale” — you won’t need it for a long time.
  • Migrations: managed DB point-in-time restore is your DR story until you have data-loss RPO requirements that say otherwise.
Rule: If you can’t explain the 9-month cost of a choice in an ADR, you don’t understand it well enough to make it.

Cost / complexity checkpoints (plain math)

This is where most stack posts hand-wave. These ranges assume ~100k MAU, ~200 RPS peak, modest data (~500GB).

  • Managed containers: $250–$900/mo all-in vs. ~20–40h/mo eng time if you run K8s yourself. At $150k eng fully loaded, that’s $1,500–$3,000/mo in hidden cost — more than the PaaS bill.
  • Datadog vs Grafana Cloud: At 500GB logs/day, Datadog can be 2–4× Grafana Cloud. If logs aren’t your product, Loki+S3 at ~30–50% lower cost is defensible.
  • Kafka too early: adds ~10–15h/mo operational load and a zoo of failure modes (consumer lag, partition rebalances) you don’t need below ~20k msg/s sustained.

When to graduate to Kubernetes

Not now, unless one of these is true:

  1. You run >12–15 services with divergent deploy rates and want uniform policy (network, secrets, scaling) across clouds.
  2. You need operators / CRDs (e.g., complex stateful workloads on Kubernetes primitives).
  3. You have a platform team (≥2 dedicated) who can own upgrades, CVEs, and node ops without starving product.

Otherwise, managed containers buy you 12–18 months. Revisit when your bottleneck is platform — not product.

Explicit recommendation

Ship: Cloudflare → Managed containers (Cloud Run / ECS / Azure Container Apps) → Managed Postgres → Redis (managed) → S3/GCS → OTel → Grafana Cloud or Datadog (choose on MTTR vs log volume) → Terraform + GitHub Actions → Clerk/Auth0. Keep service count low. Add Kafka/Spanner/K8s only when a measured constraint forces it.

What this saves you: ~3–5 weeks of evaluation time, and ~$20–50k in avoidable over-engineering for the first 12 months.

What to do next (checklist)

  1. Copy the table to an ADR; mark “swap when” triggers as alerts in your roadmap.
  2. Instrument OTel end-to-end before your first scaling incident — it’s cheaper than retrofitting.
  3. Set a quarterly stack review: if one “swap when” condition becomes true, re-evaluate just that layer — not the whole stack.

Independence note: No vendor cited here is a sponsor. Picks reflect operational leverage for a 5-engineer SaaS, not affiliate considerations. Verify compliance and data-residency needs for your jurisdiction.