Cloud bills are decided by a thousand small engineering choices and approved by people who see none of them. Planning already happens — in spreadsheets that cannot say who approved what, or what the number looked like before someone changed it. SPENDLOOP is a consumption-planning platform I designed end to end: a five-role approval chain rebuilt as an orchestrated negotiation, legible enough to act on and traceable enough to defend.
Enterprise cloud planning already has a tool. It is called a spreadsheet — and it works right up to the moment a second person needs to approve it.
I've spent years designing enterprise FinOps and IT platforms, and the pattern repeats everywhere: planning cloud consumption isn't an unsolved problem, it's a solved-in-Excel problem. A workbook per domain, a tab per month, a column someone renamed, a version emailed on Friday. It holds together because one analyst holds it together. Then the organisation asks a reasonable question — who approved this, and what did it look like before they changed it? — and the spreadsheet has no answer. Not a wrong answer. No answer at all.
The instinct is to buy a tool that replaces the spreadsheet. The instinct I wanted to design against is subtler: the spreadsheet didn't fail at arithmetic, it failed at accountability. Any replacement that models the numbers but not the decisions around them just recreates the same hole with a nicer table.
A Service Owner proposes a number. It climbs through an Eng Lead, a Domain Controller, a Portfolio Director, to a Finance Council — each seeing only the level below. That depth exists for a reason: money at this scale needs accountable sign-off. But depth is also what makes the whole thing illegible. Nobody can see who owns what, what state it is in, what changed on the way up, or why.
These two goals pull against each other, and that tension is the design problem. Simplify hard enough and you delete the audit trail that makes approval mean anything. Preserve every control and you rebuild the spreadsheet — technically complete, practically unreadable. Most enterprise tools resolve it by picking a side: either a clean dashboard nobody can audit, or a compliance system nobody can use.
The problem statement I committed to:
"Make the hierarchy legible enough that people act on it, and traceable enough that finance can defend it — with the same interface, not two."
The corollary that shaped everything downstream: if the tool can't hold the disagreement, the disagreement leaves the tool — into meetings and hallway chats where no record survives. Governance isn't lost at the moment of approval. It's lost in the argument beforehand.
This is a concept product, so I was strict about where evidence came from — domain fluency I already had, conversations I could actually have, and systems I could actually study. No invented user quotes, no fabricated metrics. One question ran through all three methods: what does a spreadsheet lose the moment approval enters the picture?
Five roles sit in the chain, but they collapse into three fundamentally different jobs: the one who knows, the ones who judge, and the one who balances the whole portfolio. Each persona is a composite of the practitioners I spoke with.
Instead of a feature-matrix against cost dashboards (which solve visibility, not negotiation), I tore down the approval mechanics of systems people actually trust with disagreement. The pattern is unanimous — and budget tools ignore it.
| System | On disagreement | Change transparency | What waits on me | After approval |
|---|---|---|---|---|
| Pull requests | Request changes → revise → same thread continues | Every diff versioned & attributed | Review queue with age | CI keeps watching the merged code |
| Expense tools | Return with a note → resubmit same claim | Amounts locked; notes visible | Approval inbox | Policy engine flags anomalies |
| Purchase orders | Counter-offer / amend cycle | Amendment history | Varies | Committed vs invoiced tracking |
| Naive budget workflows | Reject = dead; start over | Silent edits mid-chain | None — detail pages only | Nothing watches the approved number |
The whitespace isn't a missing feature — it's a missing architecture: no budget product treats the approval chain itself as the thing to design. That's SPENDLOOP's territory: workflow orchestration as the product, not a form on top of a database.
Each principle answers one research insight directly. When a screen decision got hard later, these settled the argument.
This is the heart of the project — and where I spent the most time. Enterprise workflow lives or dies on its orchestration model: which states exist, who acts in each, what happens on timeout, and how exceptions travel. I designed this layer first and let every screen be a view of it.
SPENDLOOP does not hand owners a blank field. It proposes a figure from their own history — a trailing three-month average adjusted by observed month-over-month trend — and then shows its working. Every practitioner story about padded numbers traced back to the same thing: a system produced a figure, refused to explain it, and taught people to argue with it instead of from it.
Three rules govern this number. The system proposal is never overwritten — the owner's figure is stored beside it, so the delta stays visible for the whole chain. Material deviation demands a reason, not a shrug. And a service with less than three months of history says so rather than quietly averaging a shorter window — the screen shows "2 months of history · proposal is indicative" instead of manufacturing confidence it doesn't have.
A budget is money you are allowed to spend. A cloud number is a forecast of consumption you expect to cause — usage you can only partly control, billed after the fact. Calling it a budget invites the wrong argument ("give me more") instead of the right one ("is this the usage we expect?"). SPENDLOOP calls it a consumption target, and the word "budget" appears nowhere in the product — not on a screen, not in a state, not in an export column. I keep using it on this page, in the title and the headline, because it is the category word you searched for; that split between the language you explain in and the language you ship in is itself a decision, and worth making on purpose rather than by accident.
| Term | What it means in the product — and why the distinction is load-bearing |
|---|---|
| Actual consumption | Cost already incurred in a closed month. The only number nobody can argue with. |
| Trailing average | Mean of the last three eligible months. Eligibility matters: credits, refunds and partial months are excluded and flagged, not silently averaged. |
| System proposal | Trailing average carried forward on observed trend. Immutable — it is evidence, not a draft. |
| Owner target | What the person who knows the workload actually expects. Stored separately, always shown against the system proposal. |
| Approved target | The figure the chain committed to. This is what live spend is measured against. |
| Variance | Never shown alone — always labelled with the pair being compared. "Over" is meaningless without "over what". |
Every surface is a role-scoped view of the same orchestration engine — which is why the IA is shallow. Nothing needed inventing per role; the engine's events decide what each surface shows.
The journey map that kept the team honest — well, kept me honest — about designing for the whole year, not just approval season. The emotional line to watch is the Service Owner's: the old world turns them anxious twice a year; the loop keeps them merely busy.
The riskiest bet was P·03 — making the queue the home page in a category addicted to KPI walls. I wireframed three layouts and walked each persona's first minute of a Monday through them. The dashboard-first layout lost in every walkthrough: it answered "how are we doing?" when the user was asking "what do you need from me?"
Hi-fi states for the three surfaces that define SPENDLOOP: the reviewer’s queue, the negotiation thread, and the living target. Visual language: calm neutrals, one decisive green, monospace for money — numbers should feel like facts, not decoration.
A case study that only shows outcomes hides the actual work. These are the arguments I had with myself — with the option I killed and why.
The demo always works. What decides whether a governance tool survives contact with a real org is what it does when the data is incomplete, the people move, and the calendar runs out. These are the cases I designed against explicitly — each one changed something in the model.
This is a concept, so there are no results to report — but a design is only as serious as the measurement plan behind it. These are the instruments I would put in place from day one, chosen because each maps to a specific claim the design makes.
SPENDLOOP is a self-initiated concept — the full flow work, orchestration specs, and remaining role surfaces are available as a guided walkthrough.