CASE STUDY · FINOPS / CLOUD COST OPTIMIZATION
Building a real-time cloud spend dashboard for an engineering leadership team.
- 5%Forecast within 5% of actual
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Cost feeds, allocation by team and anomaly alerts, presented in a real-time spend dashboard for the engineering leadership team.
- 1The monthly cloud bill came as a surprise.
- 2Finance saw the invoice after the month closed, and leaders learned about overruns only then.
- 3A forgotten test cluster, a data transfer spike or a looping job could run for weeks before anyone noticed.
- 4Spend could not be tied to teams or products, so the discussions that followed were arguments over who was at fault, not fixes.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In the first weeks, alerts were too noisy
Normal month-start charges, such as commitment fees, triggered warnings, and teams began to ignore the channel. We split recurring and one-off charges, excluded known monthly items from daily comparison, and set per-team thresholds with the team lead. We also limited alerts to those with a clear owner and next step.
- PROBLEM 02Trust in the alerts came back, and teams began to respond to them within the day
- PROBLEM 03A second hurdle was allocation of shared services
Teams disagreed on how to split networking, monitoring and shared databases, and one team felt it was charged for another's usage. We offered two options, split by usage where we could measure it and by headcount or fixed share where we could not, and finance chose. Putting the rule on the dashboard ended the argument.
- PROBLEM 04Putting the rule on the dashboard ended the argument
03 · THE PROCESS
How we ran it.
We ran it in short cycles with leadership as the audience.
- 01Step 1
Discovery: we interviewed engineering leaders and finance on the questions they needed answered each week.
- 02Step 2
Data: we pulled billing exports from the cloud accounts into one store and agreed allocation rules.
- 03Step 3
Dashboard: we built views by team, product, service and environment, reviewed in a weekly demo.
- 04Step 4
Alerts: we tuned anomaly detection against months of past bills, with leaders deciding what was worth an alert.
After launch, we ran two months of weekly reviews to tune thresholds and fix allocation gaps.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Leaders open the dashboard in their weekly meeting instead of waiting for the invoice.
- NOW 02
Teams receive and answer cost alerts like any other operational alert.
- NOW 03
Planned launches and migrations are entered into the forecast before they start.
- NOW 04
Untagged spend is followed up weekly.
Spend anomalies flagged within a day
- 5%
Forecast within 5% of actual
05 · WHAT WE BUILT
How it works.
- Detailed billing exports from each cloud account landed daily in a central storage bucket and were loaded into a warehouse.
- A transformation layer joined cost lines to tags, accounts and a mapping table that assigned shared costs, such as networking and support, to teams by a stated rule.
- Untagged spend appeared as its own line, shown prominently so it could not be ignored.
- Anomaly rules compared each team's daily spend with its own recent pattern, with weekday adjustments and a minimum threshold to avoid noise.
- Alerts went to the owning team's channel with the service, account and likely cause, and escalated if not acknowledged.
- A forecast used trailing trends plus planned changes entered by team leads.
- Controls
- Every number on the dashboard could be traced to a billing line item. Allocation rules were written down and versioned, so a change in how shared costs were split did not rewrite history without notice. Data freshness was shown on the page, and a pipeline failure raised its own alert so nobody trusted stale figures.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The monthly cloud bill came as a surprise. Finance saw the invoice after the month closed, and leaders learned about overruns only then. A forgotten test cluster, a data transfer spike or a looping job could run for weeks before anyone noticed. Spend could not be tied to teams or products, so the discussions that followed were arguments over who was at fault, not fixes.
- What did Brandsmashers build?
- Cost feeds, allocation by team and anomaly alerts, presented in a real-time spend dashboard for the engineering leadership team.
- How was the work run?
- We ran it in short cycles with leadership as the audience.
- What were the results?
- Spend anomalies flagged within a day; forecast within 5% of actual.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
