IT Leaders Share What Actually Cut Cloud Costs Without Slowing Delivery

We keep costs in check through our fixed monthly reviews. Every month we go through cost data across our own platform as well as every client environment, and anything that stands out as a top cost driver becomes a topic to address, the same way a bug or a feature request would.

What keeps this from going stale is treating the review as a discovery process. As our platform grows and we add clients, spending patterns shift in ways we didn't plan for going in. The monthly cadence catches that drift early, because we're looking at real, current data every time instead of merely reviewing last quarter's costs.

Running the same process for our own AWS bill and for every client is what keeps it honest. If the rule only applied to clients and not to us, it wouldn't hold up under pressure. Because we live inside the same review cycle we recommend, the discipline sticks.

Most IT pros look at login timestamps to measure software adoption and to try to save money, but it's the wrong signal. A login means "access," not "value."

To save money but not slow things down, I look at feature-level usage data. Do my employees actually host meetings on this platform? Do they use the premium features? This allows me to reclaim seats and downgrade product tiers appropriately.

Another big advantage: this all gets done when you embed approval policies into communication platforms. When you create a strong procurement portal, it will actually get circumvented by your teams as they try to move faster.

But if the approval/provisioning is via Slack, then there's no manual delay and it stays coordinated with all the internal policies. This approach stops bad software adoption in its tracks and redirects your employees to the good, managed, pre-approved alternatives.

Embedding controls on spend into the daily communication platform ensures my team is able to drive cost savings without negatively impacting the velocity of the company with periodic manual audits.

I'm Runbo Li, co-founder and CEO of Magic Hour. The single rule that changed everything for us: if a tool costs more than the time it would take AI to replace it, kill it.

David and I run a platform with millions of users as a two-person team. We don't have the luxury of letting subscriptions pile up unchecked. Early on, we were spending thousands a month on a growing stack of SaaS tools, analytics platforms, customer support software, and monitoring dashboards. Each one felt justified in isolation. But collectively they were bleeding us without proportional value.

The turning point was when I sat down one afternoon and asked a simple question about each tool: "Could I build a script, automation, or AI workflow that does 80% of what this does?" The answer was yes for about half our stack. I replaced a $300/month analytics tool with a custom dashboard built in a few hours using AI-assisted code. I replaced a $150/month scheduling tool with a simple automation. One by one, we cut tools that were solving problems AI could handle natively.

The lasting rule we adopted is what I call the "build-or-buy threshold reset." Every quarter, we revisit every active subscription and ask: has AI's capability caught up to this tool since we last evaluated it? Because the answer changes every 90 days now. Something that was genuinely worth paying for six months ago might be trivially replaceable today. That cadence keeps spending honest without creating friction, because you're never blocking a team from using what they need in the moment. You're just ensuring you don't pay for yesterday's constraints.

The signal that triggers a deeper look is simple: if usage data shows a tool is touched fewer than three times a week, it's on the chopping block immediately. Low-touch tools are the silent budget killers.

The bigger insight is this: most companies overspend on software because they treat subscriptions as permanent decisions. They're not. They're hypotheses that expire. Treat every tool like a 90-day experiment, and your spending will naturally track the pace of what AI makes free.

The decision that changed our spending for good was treating data refresh cadence as a product choice, not an infrastructure default. I run VolRadar, a bootstrapped options and volatility analytics platform, and we deliberately don't buy a live intraday feed—every metric is computed from end-of-day data, refreshed once after the close. That cadence is published on our methodology page, so it's a commitment to users rather than a quiet cost cut we can reverse under pressure. The rule I work to now: before any recurring line item gets renewed, I have to name the user-visible capability it buys. If I can't, it isn't delivery infrastructure—it's a subscription we're paying to admire.

It's a lot easier to be cautious about deploying new platforms than it is to reel them back in once your team is using them. Our approach revolves around an 80/20 rule. We want 80% of our software budget going to basically universal tools that every employee uses, and 20% going to team-specific platforms. This is reflected in how we allocate funding. We centrally control 80% and allocate the rest to individual developers and team leaders, who are better equipped to make decisions about their needs.

I changed cloud cost behavior by making cost visible when an environment is created. If a team sees spend only at invoice time, the correction comes too late and turns into a finance argument. Our standard setup starts in the client's own cloud account after we review requirements and budget. The team provisions infrastructure with Terraform and Terragrunt, bootstraps Kubernetes with Helm, and turns on cost monitoring from day one. After launch, performance against cost stays part of recurring work alongside security patching and monitoring. Every managed service needs a named business reason before it enters the stack, and every environment needs cost visibility. It's easier to approve the cost guardrail at setup, while the architecture is still easy to change.

The rule that changed behavior for me: cost is a property of how a thing is built, not a line item you negotiate afterwards. Attack it upstream and nobody has to be told no.

The clearest case I have is compute. I built a tuner for llama.cpp that sweeps the compile dimension for a given Arm chip, the architecture flags, and the quantization, and benchmarks each resulting build. Compile-flag discovery alone produced a 2–3x prefill speedup, reproduced across runs. Nothing about the workload changed. Nothing about anyone's access changed. No request got refused. The same job simply costs a fraction of what it did, because the binary is now built for the machine it runs on.

Compare that with the usual approach, a spend review where someone defends a line item to someone who doesn't use it. That produces friction reliably and savings occasionally, and it teaches teams to stop asking, which costs you more later in ways that never appear on the bill.

For genuine waste, orphaned volumes and forgotten instances, I'd automate the finding and keep a human on the deleting. I built an agent that does exactly this, and almost all the engineering went into the approval gate rather than the detection. Detection is easy. Deleting the wrong thing at three in the morning is the expensive failure, and it's the one that ends the programme.

One caveat I'd rather state than have someone discover: the compile-tuning result is specific to workloads doing heavy repetitive numeric work. I wouldn't promise anyone a similar number on a general web service.

The usual move is a top-down cost cut, and it fails the same way every time: finance freezes spending, teams route around the freeze, and you get resentment plus a shadow stack nobody logs. You didn't change behavior. You just drove it underground.

What actually worked was making cost visible to the people who spend it, then getting out of their way. The rule: every team sees its own cloud and SaaS bill, monthly, with names on it. Not finance policing them—them seeing it. It's astonishing how fast a number gets questioned once the person who created it has to look at it next to their own team's name.

The decision that changed spending for good was killing the default of "keep it running." Every recurring tool now has an owner and a renewal date, and at renewal the default flips: it turns off unless someone argues to keep it. Silence used to mean renew. Now silence means cancel. That one inversion did more than any budget meeting, because the burden moved from justifying the cut to justifying the spend.

I never blocked a team from buying a tool. Speed matters more than a few saved dollars, and a delivery slip costs more than a subscription. But I made the spend theirs to see and theirs to defend. People are careful with money they can see and own—careless with money that's abstract and someone else's problem.

The signal I trust: when a team cancels something without being asked. That's the moment cost discipline stopped being a policy and became a habit.

The rule I use is simple: every software licence must have a named business owner, an identified user or team, and a documented purpose. Ownership is then revalidated through scheduled licence audits.

I also require SaaS products to provide sufficient license inventory and usage visibility; if I cannot reliably identify licences, users and activity, I do not buy them. A named person signs off on each review and decides what to retain, reassign or remove.

This creates direct accountability without blocking teams at the point of delivery.