Nam Nguyen

From Raw Kubernetes to Self-Service

The Cost Curve Most Startups Don’t See Coming

Most startups don’t choose to build a Kubernetes platform.

They drift into it.

This is a story I’ve seen play out in a successful startup team: how Kubernetes shifts from leverage to overhead — and how the cost curve quietly flips when self-service never arrives.

---

Phase 1: Shipping fast with minimal infrastructure

Early stage feels simple.

• 3–6 senior product engineers
• One main product
• A few environments
• Deployments via cloud instances, scripts, maybe Docker

Infrastructure exists, but it’s not the focus.
Everything fits in a few people’s heads.

At this stage:

• Infrastructure work clearly enables product work
• The same engineers owning infra makes sense
• Speed beats elegance

No problems yet.

---

Phase 2: Raw Kubernetes adoption (maximum leverage)

Then growth starts to matter.

Traffic increases. Reliability matters. Someone suggests Kubernetes.

So the team adopts EKS and deploys using raw Kubernetes primitives:

• Deployments
• Services
• Ingress
• ConfigMaps
• Secrets

Still no platform team.
Still the same senior product engineers doing infra “on the side”.

And honestly — this phase works.

• Self-healing feels magical
• Deploys feel more professional
• Kubernetes delivers real leverage

Infrastructure work is maybe 5–10% of time.
The tradeoff is still clearly positive.

---

Phase 3: Human-scaled operations (the quiet shift)

This is where things change — slowly and quietly.

The company grows:

• More services
• More teams
• More environments
• On-call becomes real

Kubernetes is still running.

But now it’s running through humans, not automation.

You start seeing signs:

• Deployments require Slack coordination
• Infrastructure PRs pile up
• YAML is copied from older services
• “Don’t touch this, it’s fragile”
• “Only one or two people really understand the cluster”

The same product engineers are still doing Kubernetes work — but now it’s:

• 20%
• 30%
• Sometimes 40% of their time

This is the most dangerous phase, because it still looks cheap.

No new headcount was added.
But the cost is no longer flat.

---

Phase 4: The hidden cost curve kicks in

At this point, raw Kubernetes primitives stop being leverage.

Product velocity slows

Senior engineers spend time on:

• health probes
• resource limits
• ingress quirks
• networking edge cases

You’re paying product-engineer salaries for undifferentiated platform work.

---

Copy–paste becomes your “platform”

Without abstractions:

• Each new service copies the last one
• Bad defaults spread perfectly
• Inconsistencies fossilize

Your cluster becomes a historical archive of decisions.

---

Humans don’t scale like software

Every deploy, rollback, or infrastructure change has:

• Human latency
• Human error
• Human fatigue

Automation has an upfront cost.
Humans have a cost per action.

At scale, that math always loses.

---

Phase 5: The “guidelines” trap

This is where many teams try to fix the pain with:

• Documentation
• Best practices
• Reviews
• Wikis

But guidelines don’t remove work.
They only explain it.

The real issue isn’t bad Kubernetes usage.

It’s that Kubernetes primitives leaked into developer responsibility.

---

Phase 6: The platform inflection point

Eventually, the realization lands:

Kubernetes primitives are:

• Powerful
• Flexible
• Necessary

But they are not a developer platform.

They are the implementation layer.

Developers don’t want to deploy:

• Pods
• Services
• Ingresses

They want to deploy:

• Applications
• Web services
• Workers

This is where self-service finally enters the picture.

---

Phase 7: Self-service as the equilibrium

Self-service is not:

• Giving everyone kubectl
• Namespace admin access
• Letting teams write more YAML

Self-service means:

“I can deploy, scale, observe, and rollback my service without understanding Kubernetes internals or asking another team.”

That requires:

• One clear abstraction (for example, a WebService)
• Strong defaults
• Guardrails
• GitOps
• Automation instead of tickets

Kubernetes primitives still exist —
they’re just no longer exposed.

---

The real lesson

Starting with raw Kubernetes primitives is not a mistake.

Stopping there is.

Early on:

• Product engineers running Kubernetes is efficient

Later:

• That same choice quietly taxes velocity, reliability, and morale

The goal isn’t to remove humans.

It’s to stop using them as a deployment mechanism.

---

Closing thought

“At first, Kubernetes was leverage. Then it became a side task. Eventually, it turned into a full-time job nobody formally owned.”

If this sounds familiar, you’re not behind.

You’re just at the point where Kubernetes stops being a tool —
and starts demanding a platform.

And once self-service exists?

Kubernetes finally becomes boring again.

That’s when it starts paying for itself.