Kubernetes is a phenomenal piece of infrastructure when you have the right team running it. When you don't, it's a support burden that grows faster than your application does. This post is for the second group.
The honest assessment first
Before anything else: do you actually need Kubernetes? If you're running fewer than 8 services, have a stable team of under 10 engineers, and your deployment complexity is low — you probably don't. A well-managed ECS setup or even a disciplined EC2 + deployment pipeline will serve you better and cost less to operate.
If you're past that threshold, read on.
Managed over self-managed, always
EKS, GKE, or AKS. Pick the one that matches your cloud provider. Do not run your own control plane unless you have a specific reason that isn't "we want more control." More control means more ops burden — and ops burden is exactly what you can't afford.
GitOps from day one
The single biggest mistake small teams make with Kubernetes is manual deployments. ArgoCD or Flux. Pick one. Set it up before you deploy your first workload. The discipline it forces — every change in git, reconciliation automated, drift detected — is what keeps a two-person ops function from becoming a firefighting rotation.
"A cluster that can't explain its current state from a git commit is a cluster that will surprise you at 2am."
What to buy, what to build
Buy: ingress (use an off-the-shelf ingress controller), cert-manager, external-dns, a logging stack (Grafana Cloud or Datadog, not self-hosted ELK unless you have ops headcount to match).
Build: your deployment manifests, your Helm values, your GitOps repo structure. These are the things that need to reflect your specific architecture and can't be bought.
