Buying Cloud Commitments With a Downside Budget
The Situation
Cloud Commitment Portfolio Optimizer is a decision system for CFOs, CTOs, and FinOps leads that compares cloud commitment choices before cash is locked into a discount plan. Teams need it when billing exports, provider calculators, and spreadsheets make the downside of a one-year or three-year purchase hard to see.
The product is aimed at SaaS teams spending at least $50,000 a month across AWS, Azure, or GCP. At that level, a small sizing error can sit on the books for a full term. Provider calculators show a discount against on-demand pricing. They do not answer the finance question: what happens if usage falls, moves region, changes service, or fails to use the commitment?
The optimizer treats each purchase as part of a portfolio. It reads billing history, fixes the price evidence used for the decision, carries forecast uncertainty into the calculation, and compares expected savings with unused capacity, upfront cash, liquidity, and p95 downside loss. The output is advisory. A person still approves the commitment.
The Cost of Doing Nothing
At the product's $50,000 monthly entry point, the annualized cloud bill is about $600,000. That figure is an inference from the product threshold, not a reported customer account. A one percentage-point planning miss at that level represents about $6,000 a year before any multi-year lock-in is considered.
Spreadsheet planning makes that miss difficult to find. One tab carries last month's usage. Another carries a provider discount. Someone adds a safety margin, then the business changes. The sheet rarely preserves which price version, forecast, risk budget, and scenario produced the recommendation. When finance asks why a larger commitment was chosen, the evidence has already moved.
Doing nothing also leaves approval work scattered across messages and copied tables. The operator must rebuild the argument each month, while a reviewer has no deterministic replay to challenge. The cost is not only analyst time. It is the risk of approving a discount that saves money only while demand follows one expected path.
What I Built
I built a self-hosted planning and approval system around one rule: a recommendation must carry its own evidence. Billing files are normalized into one tenant-scoped usage history. Price tables are versioned. Forecasts retain uncertainty. Policies set a downside budget, minimum saving, utilization tolerance, allowed instruments, and approval threshold.
Before a portfolio run enters the worker, the service freezes the forecast, scenario, policy, provider, instrument, price versions, and random seed. The worker cannot silently pick newer inputs. It produces a frontier of choices and either selects a feasible candidate or records why none qualify.
The difficult part was protecting meaning across the whole path. I was wrong to treat zero as a harmless empty value for minBigInt(). During the multi-instrument expansion, that seed made every positive downside lose to zero, so a candidate carrying 6,300 cents of p95 risk produced a zero frontier summary and a zero policy relaxation. The run completed, which made the defect plausible. An infeasible-case integration test caught it across PostgreSQL and the stored frontier. The reducer now starts from the first real value.
Approvals and reports are frozen again at review time. A later price update or tenant-profile edit cannot rewrite what finance saw. If an external notification or workflow service is unavailable, the local approval remains valid.
System Flow
Data Model
Architecture Layers
The Decision Log
| Decision | Alternative Rejected | Why |
|---|---|---|
| Advisory recommendations | Automatic provider purchases | A calculation or data defect must stop at a human decision boundary. |
| Frozen run evidence | Recalculate from current account data | Finance must be able to reopen the exact decision that was reviewed. |
| Infeasible as a valid outcome | Pick the least risky available option | A policy breach is not permission to buy a weaker portfolio. |
| Versioned price tables | Trust the latest provider rate at report time | A price change must not rewrite earlier savings claims. |
| Local approval authority | Depend on an external workflow service | The core planning process must continue when an optional service is disabled. |
| Historical replay | Judge a policy from one forecast | A commitment policy needs evidence across earlier demand changes without future data leaking into the decision. |
Ecosystem Integration
Approval and risk events can pass through an event-driven notification hub, while high-value decisions can start a review in a workflow automation engine. Realized invoice comparison has a reserved boundary for the invoice reconciliation engine, but that adapter refuses outbound calls until an exact endpoint contract is verified.
All three integrations are feature-flagged. The optimizer runs standalone with no ecosystem dependencies.
Results
This is a spec build, so the proof is the release receipt rather than a claimed customer saving. The local validation on August 26 processed a 12-month replay over 1,000,000 line items in 383.38 ms against a 60-second budget. The optimizer measured 63.51 ms at p95 across 10,000 candidates and 25 iterations against a 30-second budget.
Five economic fixtures passed with exact outputs. The wider release gate passed 285 unit tests, 875 integration tests, and 13 browser flows, including import, forecast, optimizer, approval, report, and health paths. The repository moved from its June 16 bootstrap to that release receipt on August 26.
For an operator, the before-and-after is concrete: one editable estimate becomes a frozen decision packet; a headline discount becomes net savings plus downside; one current-month view becomes a 12-month replay; and a chat-based sign-off becomes an approval with preserved evidence. The next operational limit is worker concurrency and shared artifact storage, while the finance contract remains the same.