Fordel StudiosThe startup had been live for four months. They had 200 users, zero revenue, and a Kubernetes cluster running across three availability zones with Helm charts, a service mesh, horizontal pod autoscaling, and a 47-page runbook for on-call engineers. The founding team spent their weekends managing infrastructure incidents. They called it "building for scale."
They shut down eight months later. Not because the infrastructure failed. Because they ran out of money before they found a single thing users wanted to pay for. The infrastructure was irrelevant. The problem was the product.
What Kubernetes Is Actually For
Kubernetes solves real, specific problems: managing hundreds of containers across many machines, rolling deployments without downtime at scale, horizontal scaling of stateless services under variable load. These are not problems a startup with fewer than 50,000 daily active users typically has. They are problems that emerge after you have found product-market fit, grown a team, and started operating at a scale where manual deployment is genuinely impossible.
Before that point, Kubernetes is complexity you pay for constantly and benefit from never. Every engineer you hire needs to understand it. Every deployment requires it. Every incident involves it. The operational overhead is not a fixed cost — it compounds as the team grows and the system evolves. You are paying a scale tax before you have any scale to justify it.
“A single VM and a deployment script will serve your first ten thousand users perfectly. It is boring. It is also the right tool.”
Why Teams Do It Anyway
Engineers enjoy infrastructure work. It is intellectually interesting, it produces visible artefacts, and it signals technical sophistication to other engineers. Kubernetes on a resume communicates something. A simple Rails app on a single VPS communicates something different, even if the second choice was the correct one for the business. The incentive is to build impressive infrastructure, not appropriate infrastructure.
CTOs who came from large engineering organisations have another bias: they built Kubernetes-based systems at their last company and they know how to do it. They do not know how to not do it. The default is what they have already done. The startup context — where speed of learning beats technical correctness — requires a deliberate choice to do less than you know how to do.
The Infrastructure Stack for a Pre-PMF Startup
One database. One application server. A managed hosting provider who handles the boring parts. Deployments via git push. Monitoring via a single dashboard. On-call via a single phone. This is not technical mediocrity. This is appropriate tooling for a team whose primary job is to learn what users want, not to manage infrastructure.
When you hit the problems Kubernetes solves — when your deployments are genuinely causing downtime, when your single server is falling over, when you have multiple services that need independent scaling — then migrate. The migration will take two weeks. The two years of unnecessary complexity will not come back.
