Most cloud overspend I see didn't come from a bad purchasing decision. It came from a hundred small operational ones that nobody was watching: an oversized instance left running after a load test, a logging firehose that quietly tripled in volume, a dev environment that never gets switched off at night, a storage tier that was never reviewed after the data went cold.
That's the thing procurement can't fix. By the time a cloud bill reaches finance, the money is already spent. Cost control that actually works happens upstream, in the day-to-day running of the platform, which makes it an operations problem, not a procurement one.
Cost is a continuous engineering task, not a quarterly review
Rightsizing, waste cleanup, tagging discipline, reservation and savings-plan planning, anomaly detection — none of these are one-off projects. They're recurring engineering work. An idle resource doesn't announce itself; you find it because someone is looking at the telemetry every cycle and asking why a number moved. We treat cost as one of the six improvement pillars inside Critical Support for exactly this reason: it sits in the same backlog as reliability and security work, and it gets engineering hours every month rather than a frantic review when the bill lands.
You can't optimise what you can't see
FinOps starts with visibility. If you can't attribute spend to a team, a service or an environment, you can't have a sensible conversation about whether it's worth it. Putting cloud cost data alongside performance and reliability signals — in our case through Datadog and the native cloud cost tooling — turns "the bill went up" into "this service's spend rose 40% the same week we shipped that release, and here's why." That's an operational signal you can act on, not a number you explain after the fact.
Guardrails matter more than heroics
The fastest way to lose trust is to "optimise" something and break it. So the discipline cuts both ways: we don't make spend-impacting changes — reservations, commitments, rightsizing production — without sign-off, and we don't chase a saving that introduces fragility. Reserved commitments in particular are easy to buy and hard to unwind, so they get business validation before anyone clicks purchase. Good FinOps is conservative on purpose.
What this looks like for a smaller team
You don't need a dedicated FinOps function to get most of the value. For earlier-stage platforms, even the lighter Critical Support Lite model puts basic cost hygiene — tagging, waste cleanup, anomaly alerts — into the monthly rhythm. The point isn't a big cost-cutting event. It's that someone competent is looking, every month, and the savings compound quietly while you get on with building.
FinOps isn't a spreadsheet exercise you do once a year. It's an operating habit. Build it into how the platform is run, and the bill mostly takes care of itself.