Two years ago we'd have terraformed a three-region EKS cluster for a five-engineer startup without blinking. That was a mistake. Here is what we learned, in the order we learned it, with the bills attached.
The 60% rule
Sixty percent of the apps we ship would run perfectly on a managed PaaS. The remaining forty percent need orchestration — but rarely full Kubernetes. The honest taxonomy looks like this:
- Managed PaaS — Fly.io, Render, Railway. One Procfile, one database, one engineer on call.
- Container hosts — ECS Fargate, Cloud Run. Multi-service, no scheduling complexity.
- Kubernetes — only if you genuinely need workload portability, custom operators, or are running >30 services.
What goes wrong with k8s-by-default
The cluster is not the problem. The problem is everything around the cluster: the ingress, the secret store, the cert rotation, the autoscaler tuning, the multi-AZ networking, the upgrade cadence. Each piece is a half-engineer of attention you didn't budget.
"You don't pay for Kubernetes. You pay for the team that runs it."— ops principle n° 7
Our current default
For new client engagements under €50k we now default to Fly.io with a managed Postgres, a Redis, and a single CI pipeline. We measure time-to-first-deploy in hours, not weeks. We've shipped twelve projects on this stack without a single 3am page in the trailing six months.
When we do reach for k8s, it's usually for one specific reason: the client already has the platform team to run it. Otherwise, we're handing them a Ferrari with no driver.