Why We Built ClusterCost: The Story Behind the Project

Frustration with heavy cost platforms led us to a single-agent, developer-first tool.

L
Linda Cuanca
1 min read

Before ClusterCost, we tried every cost tool and spent more time operating them than optimizing our clusters. We wanted something installable in minutes that developers would actually use.

The pain

  • Tools that required multiple services and custom storage.
  • Dashboards finance loved but engineers ignored.
  • No enforcement; cost regressions still shipped.
  • Network blind spots: cross-AZ and egress weren’t visible until the bill arrived.
  • Heavy upgrades that turned “cost monitoring” into another platform to babysit.

The bet

  • Local-first: keep data in-cluster by default.
  • CLI-first: show cost where engineers work—PRs and terminals.
  • Guardrails: admission checks to block unlabeled or over-sized workloads.
  • Price-sheet driven: your rates, versioned in Git, applied in-cluster.
  • Network-aware: egress and cross-AZ visibility alongside compute.

The result

  • A single Go agent + CLI that reports cost per namespace and prevents waste.
  • Faster adoption because it looks like infrastructure, not another SaaS.
  • Happier developers: cost feedback in PRs, not after month-end bills.

We built ClusterCost to be boringly simple so teams could get back to shipping.***

👨‍💻

Linda Cuanca

Head of Sales

Read Next

Join 1,000+ FinOps and platform leaders

Get Kubernetes and ECS cost tactics delivered weekly.