How I Cut Our Infrastructure Bill by 80%

When I joined as the company's only engineer, nobody could tell me why the infrastructure bill was what it was. Not because anyone was careless. The spend had just grown the way spend always grows: one reasonable decision at a time, never revisited. Six months later the bill was 80% lower, and nothing users touch had gotten worse.

This is the playbook, in the order that actually worked.

Step 1: Read the bill like a log file

The first week, I didn't optimize anything. I built a picture: every line item across Vercel, Render, and third-party APIs, mapped to the feature it served. Two things fall out of this exercise immediately.

1. Spend you can't explain. A search-API line item on our real-estate platform was far beyond what its traffic justified.
2. Spend serving nobody. Preview environments for branches deleted months ago, an over-provisioned instance for a service receiving four requests a day.

The unexplained spend turned out to be the jackpot: a leaked API key on the real-estate platform, quietly racking up ¥100,000/month in unauthorized usage. No scanner found it. Arithmetic found it, because usage didn't match traffic. I revoked the key, rotated everything, and locked key management down.

Step 2: Cache before you resize

The instinct when a bill is high is to negotiate instance sizes. The better first move is usually to make the expensive thing happen less often:

• Search API calls on the real-estate platform dropped an order of magnitude once I cached results by normalized query. Most user searches repeat.
• Server-side renders of listing pages were being recomputed per request for pages that change a few times a day. Cache-control headers and incremental regeneration moved that work to the edge.
• The same third-party lookups were being made by two different services independently. A shared cache table ended the duplicate spend.

None of this is exotic. All of it compounds: less compute per request means smaller instances, which means the resize conversation happens from a position of measurement.

Step 3: Right-size with receipts

Only after caching did I touch plans and instances, because at that point the utilization graphs reflected the efficient system instead of the wasteful one. Overprovisioned services got stepped down one size at a time, with a week of monitoring between steps. Boring by design: each step is trivially reversible, and no single change can cause an incident.

Step 4: Make regression impossible

Cost optimization that lives in one person's memory decays. What stayed:

- Budget alerts per provider, at 50/80/100% of expected spend
- API keys: scoped per service, rotated on a schedule, never in client code
- New third-party API => cache strategy decided in the PR, not after launch
- Monthly 30-minute bill review, mapped to features (the week-one exercise, repeated)

What didn't I do?

I didn't migrate to raw AWS, even though the unit economics looked better on paper and I'm AWS-certified. With an ops team of exactly one, managed platforms are the cost optimization. My time was the scarcest resource on the balance sheet. The 80% came from eliminating waste within the platforms we already understood, which is also the version of the story where nothing broke.

The meta-lesson: infrastructure cost is an engineering metric like latency or error rate. Measure it, attribute it, alert on it. And treat every yen you can't explain as a bug until proven otherwise.