Writing
When a vendor moves the floor overnight
The cost-saving system I built worked. Then the host repriced the hardware under it, and the honest move was to measure what that meant and say it plainly. Here's how I did the math, and why being first to the bad number is the job.
The shock
One vendor, and the floor moved
A game-hosting business comes down to one number: what a gigabyte of RAM costs per month. That's the thing you're really reselling. So when the one provider underneath it raised its base prices overnight (not the first hike that year) and the cheap machines started selling out, that wasn't a rounding error. The floor moved.
One vendor had quietly become the one thing that could break both your costs and your supply at once. The whole business was priced against a single company's list, and that list had stopped standing still.
The part that's easy to misread
The mechanism worked. That's the point.
It's easy to read this as "the cost feature didn't save enough." It's the opposite. The hibernation I'd built (drop the idle CPU first, then move idle memory to disk while the server keeps running) did exactly what it was meant to. On the platform's own numbers, a server sitting on its memory idle clears around 58% margin; hand that memory back and it climbs toward 86%. That part was solved.
A vendor raising its hardware prices is a different problem entirely. One question is how much memory you waste on each machine. The other is what the machine costs in the first place. You can get the first one right and still get hit by the second, and keeping them separate is the only reason the next conversation was clear-headed instead of panicked.
The method
Check the price at the source
The reflex under a price shock is to pull up a comparison site and grab the cheapest row. The comparison sites were wrong: stale prices, phantom stock, regions that didn't actually have capacity. So I checked every provider's real per-GB price on its own pages, converted currencies on a fixed date so a euro plan and a dollar plan were honestly comparable, and counted DDoS protection as a real cost line, because for game servers it isn't optional.
What came out of it: the cheap EU and US regions all sit near the same floor, and somewhere like Australia runs two to three times that. A premium you price in on purpose, not one you discover after you've promised a tier there.
The answer wasn't a different single vendor. It was to stop depending on any one of them: a primary provider, a backup ready to take over, and cloud capacity to soak up the spikes. With that in place, the next overnight price hike is an annoyance, not an emergency. The exact prices in that analysis are already out of date, and that was always going to happen. The numbers were never the point. Not being locked to a single vendor was.
The outcome
I gave them the number. The call was theirs.
I laid out the whole picture (the new economics, the alternatives, what going portable would and wouldn't fix) and the studio chose to pause. I didn't argue for it and I didn't argue against it. The job they were paying for was to know the real number and not blink, and that's what I did.
Whoever's holding your infrastructure, this is the trait you actually want: when the math stops working, you hear it from them first, with the numbers attached, while you can still do something about it.
The lesson
Same discipline as inference spend
Two things carry out of this. One, leaning on a single vendor is a risk whether or not you've ever priced it, and the time to build a way out is before the price moves. Two, find your binding cost (the one resource that actually caps the business) and engineer against that, not against a dashboard total.
It's the same muscle that protects an AI product. There the binding cost is inference, and the questions don't change: what does a unit of work really cost when you measure it at the source instead of the invoice, where's the waste, and what happens to your margins the day a provider reprices. Cost work belongs in the system, not in a quarterly review.