Murdock Labs

"Should we use Kubernetes?" is the infrastructure equivalent of tabs vs. spaces. Everyone has an opinion. Here's ours, based on running K8s for startups of all sizes.

The Honest Answer

If you have to ask, you probably don't need it yet.

Kubernetes is a platform for running platforms. It solves real problems — but only if you actually have those problems. Most startups under 20 engineers don't.

When Kubernetes Makes Sense

You need K8s when:

You're running 20+ microservices that need independent scaling
You have multiple teams deploying independently
You need sophisticated traffic management (canary deployments, A/B testing)
You're multi-cloud or hybrid-cloud for compliance reasons
Your traffic patterns are highly variable (event-driven spikes)

Real example: One of our clients runs a data processing platform. They process 50M events/day, but 80% of that volume hits in a 4-hour window. Kubernetes autoscaling saves them 60% on compute vs. provisioned capacity.

When Kubernetes Is Overkill

Skip K8s when:

You're a team of 1-10 engineers
Your app is a monolith or has fewer than 5 services
Your traffic is predictable
You don't have a dedicated platform/DevOps engineer
You're pre-product-market fit (optimize for speed, not scale)

What to use instead:

Single server: Seriously. A $50/month VPS can handle more than you think.
PaaS: Railway, Render, Fly.io — deploy in minutes, scale when needed.
Serverless: Vercel, AWS Lambda — great for event-driven workloads.
Managed containers: AWS ECS, Google Cloud Run — containers without K8s complexity.

The Middle Ground

Most of our clients land here:

Start with PaaS (Vercel + Railway or similar)
Move to managed containers when you need more control (ECS/Fargate)
Graduate to K8s when you have the team and complexity to justify it

This progression lets you focus on your product while getting progressively more infrastructure control as you need it.

The Hidden Costs

If you do go K8s, know what you're signing up for:

Operational overhead: K8s requires ongoing maintenance, upgrades, and debugging
Learning curve: Your team needs to learn Helm, networking, RBAC, etc.
Debugging complexity: When something breaks in K8s, it breaks in interesting ways
Cost: Managed K8s (EKS, GKE) has a base cost before you add any compute

We've seen startups spend 30% of their engineering time on K8s operations. That's 30% not spent on your product.

Our Recommendation

Unless you have a specific, concrete reason to use Kubernetes, don't. Start simple. Migrate when the pain of simplicity exceeds the cost of complexity.