Do You Actually Need Kubernetes? (For 95% of Startups: No)

Roughly one in three architecture audits I run for sub-20-engineer startups ends with the same recommendation: rip out Kubernetes. The founder always pushes back. The senior engineer who originally set it up always pushes back harder. Six months later, after the migration, almost nobody regrets it.

Kubernetes is a fine technology. It is also a technology that solves problems most startups do not have, at a cost most startups cannot afford to pay in attention. This is the post I send before I do the audit, so the founder knows what to expect.

The case against Kubernetes for startups

For 95 percent of startups under 50 engineers, Kubernetes is the wrong default. The cluster fee is the cheapest part. The expensive parts are the human costs and the opportunity costs.

The four costs nobody quotes when they pitch you Kubernetes:

1. Senior DevOps salary: a real Kubernetes operator costs $180K to $250K loaded in the US, $80K to $140K in Europe and LATAM. If you do not have one, your cluster is a time bomb. If you do, that is one fewer product engineer.
2. Debugging surface area: every layer (pod, deployment, service, ingress, network policy, RBAC, etc.) is a place a bug can live. A 4-hour outage caused by a misconfigured PodDisruptionBudget is not a story your investors want to hear.
3. Distraction from product: founders and engineers who should be talking to users end up talking to YAML. The cumulative time cost over 12 months is staggering and shows up as 'we never had time to ship that feature.'
4. Tooling churn: the Kubernetes ecosystem moves fast. Helm, Kustomize, Argo, Flux, ArgoCD, Tilt, Skaffold — picking and maintaining a stack is itself a part-time job.

The 'premature Kubernetes' anti-pattern

Premature Kubernetes is the 2026 version of premature optimization. The pattern: a senior engineer joins (or is hired specifically for infra), reaches for the platform they used at their last company (usually a 500+ person org), and spins up a cluster on day 30. By day 60, the team is debating Helm vs Kustomize. By day 120, the founder is asking why deployments take 2 days instead of 2 hours.

The error is using a Series C company's playbook at a seed company. Kubernetes is built for the org that has it, not for the org that aspires to it.

Kubernetes is a platform for building platforms. It's a better place to start than to end.

— Kelsey Hightower

That quote, from one of the people most associated with making Kubernetes accessible, is the single most underrated piece of infra advice in our industry. If you are not building a platform — if you are building a product — Kubernetes is not your starting point.

What to use instead, by workload

The 2026 deploy-target landscape is excellent, and it has gotten better every year. Almost every startup workload up to $10M ARR fits cleanly into one of these without ever touching a Helm chart.

Notice what each of these shares: managed control plane, simple deploy command, predictable pricing, and a cap on how much complexity they can spawn. They are constrained on purpose. The constraint is the feature.

When Kubernetes is actually justified

I am not anti-Kubernetes. There are real workloads where it is the correct answer, and pretending otherwise would be cargo-culting in the opposite direction. Three legitimate scenarios:

Scenario 1: 50+ engineers across multiple teams

When you are 50+ engineers shipping independently, you need a real platform layer to give each team isolated deploys, resource quotas, and consistent tooling. Kubernetes earns its keep here because the alternative is each team rolling their own infra, which gets worse faster than Kubernetes does.

Scenario 2: Multi-region stateful workloads with pod-level needs

Specifically: distributed databases, stream processors, gaming backends, or anything where you genuinely need to control which pod runs where, with which resources, across regions. PaaS platforms hide this; Kubernetes exposes it. If your workload genuinely requires this control, use it.

Scenario 3: Enterprise procurement requirement

Some enterprise buyers — particularly in regulated industries — require Kubernetes-shaped deployments because their internal platform is built around it. If your buyer is in that bucket and your contract value justifies it, Kubernetes is part of the cost of selling to them. This is rare for early-stage startups but real for late-stage ones.

The cost comparison: Kubernetes vs Render at small scale

Real numbers from a recent audit. Mid-stage SaaS, 5 engineers, roughly 200K monthly active users, US-only.

Their existing setup, EKS-based:

• EKS control plane: $75/month
• 3 m5.large worker nodes: ~$210/month
• RDS Postgres (medium): $180/month
• Application Load Balancer + traffic: ~$60/month
• Observability (Datadog, partial coverage): $400/month
• Total cash: ~$925/month
• DevOps engineer (50 percent of time): ~$8,000/month loaded
• All-in monthly cost: ~$8,925/month

Equivalent setup we migrated them to:

• Render Standard plan, 2 services: $50/month
• Render Postgres (4GB plan): $90/month
• Cloudflare in front: $20/month
• Better Stack observability: $50/month
• Total cash: ~$210/month
• DevOps engineer time: ~5 percent (essentially the founder skim-reading deploy logs)
• All-in monthly cost: ~$210/month + de minimis attention

Annualized savings: roughly $100K cash plus most of a senior engineer's attention. The migration took 3 weeks of platform engineering work. Payback period: about 5 weeks.

I am not saying Render is always cheaper than EKS. I am saying that for a 5-engineer shop with 200K MAU, the cost gap is not subtle. And this is the modal startup, not the edge case.

How to migrate off Kubernetes (if you should)

If you have read this far and quietly suspect you are the 95 percent, here is the playbook I run when an audit recommends ripping out Kubernetes.

1. Audit your workloads — list every service, its dependencies, its stateful requirements, and its current resource usage. Most teams discover 30 to 50 percent of their cluster runs services they could turn off.
2. Map each workload to a target platform — web frontend to Vercel, stateless APIs to Cloud Run or Render, stateful services to Fly.io or ECS Fargate, database to managed Postgres.
3. Migrate stateless workloads first — they are easier to roll back, and they validate the new platform without risking data.
4. Migrate the database next, with a careful cutover plan — usually a read-replica promotion or dump-and-restore depending on volume.
5. Migrate stateful and orchestration-heavy workloads last — these are the hardest, but by the time you get to them, you have built confidence in the new platform.
6. Decommission the cluster — only after the new platform has run a full month with no incidents. Do not skip this step; running both in parallel forever is the cost trap.
7. Document the new operational runbook — what does deploy look like, what does on-call look like, how do you debug. The whole team should be able to operate the new platform without a specialist.

Total elapsed time for a sub-20-engineer team: 4 to 12 weeks depending on workload complexity and how much hidden state lives in the cluster.

What to do if you are pre-Kubernetes

If you are pre-build or post-MVP and have not yet committed to Kubernetes, the answer is simple: do not.

Pick a managed platform that fits your stack (Vercel for Next.js, Render for general-purpose, Fly.io for stateful or geographic workloads, Cloud Run for stateless APIs) and ship. You can revisit Kubernetes when you cross 50 engineers or when a real workload need pushes you there. You will know when that is, and it will not be in your first 3 years.

If a senior engineer on your team is pushing for Kubernetes 'because we will need it eventually,' ask them: 'when specifically?' If the answer is not 'when we hit X concrete trigger,' it is a culture or resume signal, not a real technical need.

How my audits handle this

Architecture audits I run (from $1,499) cover deploy infrastructure as one of six core areas. About a third of audits for sub-20-engineer teams produce a 'rip out Kubernetes' recommendation, with a written migration plan and target platforms. The audit pays for itself in 4 to 8 weeks once the migration is done.

If you are running Kubernetes and feeling friction, an audit is the cheapest way to get a written second opinion before committing to a migration. If you are pre-build and want a senior to make the deploy-target call for you, the MVP Build Sprint includes an opinionated deploy choice as part of the package.

For more on related architecture decisions, see the post on Postgres vs MongoDB for startups — same principle applies (use the boring, mature, easy thing until something forces your hand) and the fractional CTO cost breakdown if you want a senior on retainer to make these calls week to week.