Kubernetes Is Overengineered for 90% of Startups

I've run Kubernetes in production. I've migrated companies to Kubernetes and, more interestingly, I've helped a few migrate away from it. And after watching the pattern repeat itself across a dozen organisations — from Series A startups in Manchester's Northern Quarter to enterprise teams in London — I'll say the quiet part out loud:

Most startups have no business running Kubernetes.

Kelsey Hightower — one of Kubernetes' most prominent advocates, co-author of Kubernetes: Up and Running, and the closest thing the project has to a patron saint — has been publicly honest about this for years. "We have to stop using Kubernetes as a hammer for every nail," he said at KubeCon. If the person who helped evangelise K8s to the world is urging restraint, it's worth listening.

---

The Problem Isn't K8s — It's Timing

Kubernetes is a genuinely impressive piece of engineering. It solves real problems: workload scheduling, self-healing, horizontal scaling, service discovery, rolling deployments. If you're running hundreds of microservices across multiple availability zones, it's arguably the only sane choice.

But here's the uncomfortable maths:

• Setting up a production-grade K8s cluster (with proper RBAC, secrets management, networking policies, autoscaling, and observability) takes 3–6 months of a skilled DevOps engineer's time.
• Maintaining it is a part-time job in perpetuity.
• The majority of startups that adopt K8s at series A or earlier have fewer than 10 services.

You're building a system designed to manage thousands of containers, and you have seven. That's like buying a fleet management platform to track your car.

---

The Real Cost Nobody Advertises

The tech blogs celebrate the migration. They don't write about what comes next.

Cognitive overhead. Every engineer on your team now needs to understand pods, deployments, services, ingress controllers, ConfigMaps, Secrets, PersistentVolumeClaims, namespaces, and Helm charts — just to deploy a feature. Junior engineers are paralysed. Senior engineers are distracted.

Operational burden. Who monitors the control plane? Who handles node upgrades? Who owns the etcd backups? Who debugs CrashLoopBackOff at 2am on a Saturday? If you don't have a platform engineering team, the answer is "everyone and no one."

The abstraction tax. Your developers wanted to ship features. Instead, they're writing YAML. Thousands of lines of YAML. YAML that describes YAML templates (Helm) that generate more YAML. If you squint hard enough, you can see your product roadmap fading into the horizon.

---

What You Probably Need Instead

I've seen startups run clean, reliable, scalable infrastructure on:

• A single well-configured ECS cluster — AWS's container orchestrator that most engineers find actually readable
• Railway, Render, or Fly.io — platforms that handle the orchestration so your team doesn't have to
• Docker Compose on a couple of beefy VMs behind a load balancer — boring, but it runs Basecamp

These aren't compromises. They're appropriate choices for your current scale. Instagram ran on Django and Postgres for years before needing anything exotic. Shopify ran on a monolith until it genuinely couldn't. DHH and the team at 37signals — the people behind Basecamp and Hey — famously run millions of requests a day on what they call a "Majestic Monolith," with a small infrastructure footprint and a tiny ops team. They've written extensively about the freedom that comes from rejecting complexity as a proxy for sophistication.

Martin Fowler made the same point more formally in his Microservices writing: "Don't start with microservices. Start with a monolith and break it apart when — and only when — the scaling pressures actually demand it." The same logic applies to orchestration. Don't start with K8s. Start with something you can actually operate.

---

When Kubernetes Does Make Sense

To be clear: I'm not anti-Kubernetes. I'm anti-premature-Kubernetes.

K8s earns its complexity when you have:

• Genuine multi-tenancy requirements that need hard isolation at the container level
• Varied workload profiles — CPU-heavy batch jobs alongside latency-sensitive APIs
• A dedicated platform engineering function that owns the cluster, not the feature teams
• Scale that actually requires bin-packing and workload scheduling across a fleet

If you check all four boxes, ship it. If you're checking one and hoping the others follow, slow down.

---

The Counterargument Worth Taking Seriously

The strongest argument for early K8s adoption is skill building and hiring. Engineers want to work on K8s environments. It's a signal that a company invests in modern tooling. And if your team needs to learn it eventually, why not start now?

It's a reasonable point. It's also exactly the kind of argument that gets infrastructure teams building cathedrals when you need a lean-to.

I've interviewed hundreds of engineers across the North West and beyond. The ones I've consistently found most valuable aren't the ones who know every Kubernetes operator — they're the ones who can look at a problem and choose the right level of complexity for where the business actually is. That judgement is rarer and harder to hire for than YAML fluency.

Hire engineers who can make pragmatic infrastructure decisions. That's worth more than any particular tooling choice.

---

The Challenge

If you're currently on Kubernetes with fewer than 20 services and no dedicated platform function: do the honest calculation. Add up the engineering hours spent on cluster operations over the last quarter. Now ask what feature work that time would have shipped.

The answer might surprise you — and your investors.

Disagree? I'd genuinely enjoy hearing from someone who adopted K8s at five engineers and would make the same call again. Book a call or reach out on LinkedIn.