If your startup is fewer than 30 engineers and you are not deploying the same software into a customers AWS account, Kubernetes is almost certainly a mistake. Not a "maybe later" trade-off. A mistake, right now, in 2026, that is burning money and slowing shipping.

This is not a hot take. The 2025 State of Production Kubernetes report from Spectro Cloud surveyed 455 platform engineers and found that cost overtook skills and security as the #1 challenge, with 42% of teams flagging it and 88% reporting year-over-year cost increases. That is a survey of people already running Kubernetes at scale. If cost is the #1 pain for them, imagine what it is doing to you.

The argument you have probably heard

The pro-Kubernetes pitch is a list of hypothetical problems:

  • "We will need to scale to millions of users."
  • "We will need multi-cloud to avoid lock-in."
  • "We will need to deploy into customer environments."
  • "Kubernetes is the industry standard, recruiters expect it."

On an Hacker News thread asking whether K8s is still a no-no for early-stage startups in 2025, the dominant reply was: "Kubernetes is a solution to problems that you do not have, while it creates new problems that you do not currently have." Most of the people who said "use it" had a very specific reason (on-prem for customers, multi-cloud for legal reasons, or already a K8s expert). Most of the people who said "skip it" were running real businesses.

The real cost is not the cloud bill

A well-documented case study from January 2026 tracked an 8-engineer SaaS company that moved to AWS EKS for 5 microservices and 12,000 users. Numbers:

  • Monthly infra cost: $153 (two VMs, Docker Compose) -> $783 (EKS + 3 nodes + 3 load balancers) -> $168 after they migrated back.
  • Deploy time: 5 minutes -> 45 minutes -> 4 minutes.
  • Engineer time on infra per week: 5 hours -> 60 hours -> 6 hours.
  • Production incidents per month: 2 to 3 -> 8 to 12 -> 2 to 3.

The cloud bill went up 5x. The hidden cost was the 55 hours per week the team lost. That is more than a full-time engineer, redirected from shipping features to fighting Helm charts.

A separate analysis of small-team Kubernetes overhead put the realistic staffing number at 4 dedicated DevOps engineers (about $564K/year) for "reliable production K8s." Most startups do not have those people. They have backend devs who "also do DevOps." That is where the 3 AM pages come from.

When you actually do need Kubernetes

The opposite take is also wrong. K8s is genuinely good at a specific thing, and pretending otherwise is just as dishonest as pretending it is the right default.

You probably do need it if:

  • You deploy into customer-owned cloud accounts (regulated industries, defense, telco). The Spectro Cloud report notes 68% of respondents run most of their estate on K8s and 31% are betting on KubeVirt for VM workloads. This is real-enterprise work.
  • You genuinely need multi-cloud for legal or pricing reasons. The same survey shows enterprises running 5+ environments across 20+ clusters. If you are one of those, congratulations, you are not a startup anymore.
  • You have 50+ microservices with complex dependencies and a real platform team. Not "the backend lead who reads the K8s blog."

WhatsApp famously served 900 million users on FreeBSD and Erlang with 50 engineers. Discord started on simpler infrastructure. The lesson is not "use FreeBSD" but "the right tool at the wrong time is the wrong tool."

What to use instead

The default stack for a 2 to 20 engineer team in 2026 is one of three:

  1. Render or Railway for the app. Fixed pricing, Postgres included, push-to-deploy, no YAML. A 2026 pricing comparison puts a small always-on app at $6 to $25/month. You can get to product-market fit on that.
  2. Fly.io if you need edge / multi-region latency. Slightly more complex, but it stays out of your way.
  3. AWS App Runner, Google Cloud Run, or Azure Container Apps if you are already locked into a cloud. Container in, HTTPS and auto-scaling out. Stays inside the same ecosystem, so you can graduate to ECS or EKS later without rewriting.

If you want to stay on bare metal: a $60/month Hetzner box, Docker Compose, and an Ansible playbook. Not sexy, but boring infrastructure ships features.

A real example we have seen

For a small B2B SaaS client (3 engineers, 4 services, ~2,000 users), the original setup was ECS Fargate. Reliable, but every deploy needed a custom CodePipeline and the team was scared to ship on Fridays. We moved them to Render with managed Postgres in a weekend. The deploy command went from "open AWS console, click 4 things, wait 12 minutes" to git push. Monthly bill dropped from about $310 to $45. Nobody has been paged about infrastructure since.

That is not a Kubernetes success story. That is the absence of a Kubernetes story, which is exactly the point.

The bottom line

Kubernetes is a powerful tool for a small set of problems. The 2025 data, the case studies, and the on-the-ground experience all point in the same direction: it is a tax you pay for problems you do not have yet, and the tax compounds every week you are not shipping.

Build on a PaaS. When you have 30 engineers and 50 services, revisit. Until then, the most senior move in infrastructure is the one you do not make.