When Not to Use Kubernetes: The EM Scorecard
A few months back I wrote Kubernetes Is Not the Answer for Everything. It got passed around. Most of the responses I got were variations of the same question, and they came almost entirely from engineering managers and early-stage founders.
“Okay. So how do I tell my team we don’t need it?”
This post is the answer. A scorecard you can run in fifteen minutes that gives you a defensible call you can show your team, your CTO, or your board.
When should you not use Kubernetes?
You should not use Kubernetes when you have fewer than five engineers, fewer than ten services, predictable traffic, and no compliance mandate that requires it. In that situation, Docker Compose on one or two servers, a PaaS like Fly.io, or HashiCorp Nomad will ship faster, break less, and cost a fraction of the operational overhead. Kubernetes earns its complexity at scale. Below that threshold, it’s a tax with no return.
That’s the answer. The rest of this post is the scoring system that gets you there.
The Scorecard
Run each row. Add the points. The total tells you what to use.
| Signal | 0 points | 1 point | 3 points |
|---|---|---|---|
| Engineers shipping to prod | 1–4 | 5–15 | 15+ |
| Services in production | 1–3 | 4–10 | 10+ |
| Independent deploy cadence | One team, one cadence | 2–3 teams, occasional conflicts | 3+ teams, daily conflicts |
| Traffic profile | Predictable, single region | Spiky but bounded | Unpredictable, multi-region |
| Compliance posture | None or shared platform handles it | SOC2 in progress | HIPAA, PCI, FedRAMP, multi-tenant isolation required |
| Stateful workload count | Database + cache, that’s it | A few queues and search indexes | Many stateful services, custom operators |
| Multi-cloud or hybrid mandate | One cloud, one region | Disaster recovery in a second region | Active-active across providers |
| Hiring market reach | Local team, generalist hires | Hiring nationally | Hiring globally, K8s on the JD |
How to read your score
| Score | Recommendation |
|---|---|
| 0–4 | Docker Compose on one server, or a PaaS (Fly.io, Railway, Render). You are nowhere near needing K8s. |
| 5–9 | Nomad, ECS, or Compose with a real CI/CD pipeline. K8s would slow you down. |
| 10–15 | The boundary. K8s might be right. So might a managed PaaS that hides 90% of K8s. Decide based on hiring and compliance, not architecture. |
| 16+ | Kubernetes is probably the right call. The complexity tax is now cheaper than the alternatives. |
If your score is 9 and someone on your team is pushing for K8s, ask them which row of the scorecard they’re trying to move. If the honest answer is “it’ll look good on the team’s résumés,” you have your answer.
What does the scorecard actually measure?
It measures whether the things Kubernetes is good at apply to your situation. Not whether Kubernetes is good in the abstract. It is. But whether the specific problems it solves are problems you have today.
K8s solves four classes of problem well:
- Multi-team coordination at scale. Namespaces, RBAC, GitOps. If your engineering org is one team, you don’t have this problem.
- Heterogeneous workloads with shared infra. Lots of services with different runtimes and scaling profiles. If you have one Rails app and a Postgres, you don’t have this problem.
- Auto-scaling under unpredictable load. HPA and cluster autoscalers. If your traffic is predictable, you don’t have this problem.
- Compliance and isolation guarantees. Network policies, pod security, admission controllers. If you’re not in a regulated industry, you don’t have this problem.
The scorecard is just those four things, broken into observable signals.
Why do engineering managers default to Kubernetes anyway?
Three reasons, in roughly the order I encounter them:
The default-bias. Conference talks, vendor blog posts, and HN comments make K8s look like the only serious option. Survivorship bias: you hear about companies running K8s because they blog about it. You don’t hear from the thousands shipping happily on a single VPS.
The platform-team forecast error. “We’ll outgrow Compose in six months, so let’s just start with K8s.” That sentence costs more than every other sentence in engineering put together. Six months is also when you’ll learn what scaling problems you actually have, and they will not be the ones you predicted.
The hiring narrative. “We need K8s on the JD or we won’t attract senior engineers.” Maybe true at FAANG-scale. Almost certainly false for a fifteen-engineer startup. The senior engineers worth hiring know the scorecard already.
The decision tree, after the scorecard
flowchart TD
A["Scorecard total"] -->|"0-4"| B["Docker Compose<br/>+ Caddy/Traefik<br/>or PaaS"]
A -->|"5-9"| C["Compose at scale<br/>or Nomad<br/>or ECS"]
A -->|"10-15"| D["Compliance mandate?"]
A -->|"16+"| E["Kubernetes"]
D -->|"Yes"| E
D -->|"No"| F["Multi-team friction?"]
F -->|"Yes"| E
F -->|"No"| G["Managed PaaS<br/>or Nomad"]The thing to notice: even at the high end of the score, you have outs. Managed PaaS options have closed most of the gap to K8s for orgs that don’t need raw cluster control. Render, Fly Machines, and Railway can run multi-region, multi-team, autoscaled workloads without ever exposing you to a kubectl command.
What does graduating to Kubernetes actually look like?
If your scorecard told you to start on Compose and you’re now hitting limits, the migration is real but not dramatic. The signal is usually one of three things:
- A second team is asking for an isolated deploy pipeline. That’s RBAC and namespaces talking. Compose can’t help you here.
- Your stateful service count is growing and operators would help. Postgres operator, Kafka operator, Elastic operator. K8s’ operator pattern is genuinely great for this.
- You’re paying for over-provisioning to absorb spikes. HPA buys real money back at this scale.
When that happens, migrate. Don’t migrate before. The cost of moving from Compose to K8s when you actually need it is much lower than the cost of running K8s for two years before you needed it.
A note for founders specifically
If you’re a founder reading this and your engineering lead is pushing for Kubernetes on day zero, here’s the one question to ask:
“What problem does this solve that we have today?”
Not “what problem might it solve in two years.” Not “what problem do other startups have.” What problem do we have, today, that K8s solves and the alternative doesn’t.
If they can’t name one, the scorecard already has your answer.
FAQ
Is Kubernetes overkill for a startup?
For most early-stage startups, yes. If you have fewer than five engineers, fewer than ten services, and no compliance mandate, the operational overhead of K8s outpaces its benefits. Docker Compose, Fly.io, or Render will ship faster and cost less.
Can you run production workloads without Kubernetes?
Yes. Plenty of profitable companies run production on Docker Compose with a reverse proxy, on Nomad, on managed PaaS platforms, or on a single well-configured VPS. Kubernetes is one option, not a requirement.
When should a startup adopt Kubernetes?
When the scorecard above totals fifteen or more. That means you have multiple teams shipping independently, ten or more services, real compliance mandates, or unpredictable multi-region traffic. Before that, the K8s tax outweighs the benefit.
What are the best Kubernetes alternatives in 2026?
HashiCorp Nomad for orchestration, Fly.io and Render for managed PaaS, Kamal for deploying containers to bare servers, and Docker Compose with Traefik or Caddy for single-server setups. Each handles a slice of what K8s does with much less operational cost.
How do you migrate from Docker Compose to Kubernetes?
Start with a managed K8s service (EKS, GKE, AKS) so you don’t run the control plane yourself. Move stateless services first. Keep databases on managed services or operators. Use Helm or Kustomize for manifests from day one. Plan three to six months of dual-running to catch surprises.
Rule of thumb
Pick the simplest thing that works today. Graduate to Kubernetes only when the scorecard tells you the pain of simplicity has exceeded the cost of complexity.
That’s it. The boring answer is usually the right one.
If you’re an EM or a founder running this scorecard and your number lands in the 10–15 grey zone, that’s the conversation I’m built for. Get in touch.