BetterSWE DigestWhat is BetterSWE?

System Design · Issue 17

The startup that almost died migrating to Kubernetes for non-technical reasons

187 users, $12,400/month on AWS. A $24 VPS saved the company.

A small office overwhelmed by a massive Kubernetes cluster

The setup

187 users, $12,400 a month

A small office overwhelmed by a massive Kubernetes cluster

A seed-funded startup had 187 active users, a product priced at $29/month, and an AWS bill of $12,400/month. That is roughly $66 per user per month, more than twice what each user paid.

Cargo cult architecture

The architecture was 8 microservices across 47 pods on 12 nodes. An ex-Google CTO had brought FAANG-scale infrastructure to a company with no traffic, and "we use Kubernetes" looked good on a fundraising deck.

8 microservices, 47 pods, 12 nodes. For 187 users.

Frank de Jonge noted that when startups suffer mayhem with K8s, "chances are overwhelmingly big the problem is not Kubernetes." Kubernetes only makes sense with a platform team of 6-8 FTEs and 100+ developers, a bar this startup was nowhere near.

The operational tax

60% of engineering on plumbing

Engineer overwhelmed by Kubernetes YAML configuration

With 187 users, 60% of engineering time went to keeping the cluster alive. A DNS timeout between the Auth and User services took 40 hours to debug and required 47 lines of retry logic. Zero features shipped that week.

Where the time went

Each microservice added a new failure surface: inter-service network hops, YAML configurations, pod scheduling, ingress controllers. The product itself was simple. The complexity lived in the plumbing between services.

A single user request bounces through 4 services. Each hop adds latency and a new failure surface.

The industry has a name for this: the complexity tax of Kubernetes, where YAML burnout and hidden operational costs consume engineering time that should go to features. Migrations routinely blow past estimates because of hidden complexities like ephemeral pod storage and broken legacy assumptions.

The outage

Tuesday, 11:34 PM

Data center outage with one small server still running

At 11:34 PM on a Tuesday, a routine OS patch on a worker node triggered a cascade failure that took all services offline. The team burned $340 in AWS costs trying to restart the cluster. By 4:15 AM, the backend engineer bypassed Kubernetes entirely and deployed the whole stack to a single DigitalOcean droplet costing $24/month.

The $24 droplet beat the 12-node cluster on latency, uptime, and cost.
  1. 11:34 PM (OS patch triggers cascade)
  2. $340 burned (AWS costs trying to recover)
  3. 4:15 AM (Deployed to single VPS)
  4. 14 min later (System back online)

The results: 47ms average response time, lower than the K8s setup because there were no inter-service network hops. 99.97% uptime, zero incidents over 8 days. The Kubernetes failure stories archive documents this pattern of routine operations triggering cluster-wide outages.

How long until they outgrow the droplet?

The engineer estimated the single-server setup could handle 50,000 concurrent users. At their growth rate of 2.1% month-over-month, it would take 9.7 years to outgrow the simple architecture. They would run out of money long before they ran out of server capacity.

The tradeoff

$24 vs. $12,400

Single server running successfully with growing revenue

Month 10: the lead investor saw production running flawlessly on the $24 droplet and ordered the CTO to kill the cluster. The AWS bill dropped from $12,400 to $180/month, and roughly 100 hours of engineering time was freed up each month.

They shipped 7 features that month. By Month 13, the company hit profitability with $34,000 MRR.

Kubernetes

$12,400/mo, 60% eng time, 0 features/wk

Monolith on VPS

$180/mo, 5% eng time, 7 features/mo

Month 18: raised an $8M Series A at a $45M valuation, praised for capital efficiency. Month 24: 2,847 users, $127K MRR, infrastructure at $890/month, 12 engineers, 0 Kubernetes clusters. The boring monolith was enough.

The lesson

Boring architecture wins

Why it matters

The story is a concrete version of a pattern playing out across the industry. Startups adopt the infrastructure of companies orders of magnitude larger, then watch their burn rate climb and feature velocity collapse. A $24 VPS and the willingness to choose boring architecture let this company survive long enough to find product-market fit.

The short version

  • The startup spent **$12,400/month** on Kubernetes for **187 users**, with **60% of engineering time** consumed by infrastructure.
  • A cluster outage forced a deployment to a **$24/month VPS**, which had better latency, uptime, and cost.
  • The pivot to a monolith cut the AWS bill to **$180/month** and freed **100 hours/month** of engineering time.
  • The company reached profitability within 13 months and raised an **$8M Series A**, praised for capital efficiency.
  • Kubernetes makes sense with **6-8 platform FTEs** and **100+ developers**. Most startups have neither.

Sources

  1. 1.How all of these “Kubernetes almost killed my startup” sound to me: I saw a well-funded startup run itself into the ground. The cause? A butter knife! Before they had butter knifes, they used… | Frank de Jonge | 16 comments
  2. 2.Medium
  3. 3.Migrating to Kubernetes, part 2: Why it’s hard | Benjamin Yolken
  4. 4.So you want to migrate to Kubernetes: observations from a software ...
  5. 6.Kubernetes Failure Stories