Cloud spending plans · Closed beta

Optimize your cloud spend.A spending schedule with no surprises.

OpexOpt finds the savings your company permits and turns them into a dated spending schedule. Every planned cost, commitment, and decision is visible before it reaches your budget.

BasisSavings are measured against your agreed baseline. Forecast ranges show how demand could move each month, and every review explains what changed and why.

Request a review See how it works

Cumulative cash · 36 months · USDExample plan · anonymized

On-demand costPlanned cashForecast range

01What to change
02What to buy
03When to act

Lower cloud cash, 36 months

26%

$3.2M planned against $4.3M at on-demand prices

Cash kept for the Series B

$1.13M

Credits used first, then one-year commitments

Forecast range for cash

$2.7M–$3.8M

10th to 90th percentile of simulated demand

Cost per simulation run

−65%

$0.62 → $0.22 on Arm instances, in one benchmark

01 / How it works

From your business activity to a spending plan.#

Start with two or three processes, agree which savings tools are allowed, and compare their combined effects before choosing a plan. Select any item for details.

Step 01
Model 2–3 key processes
Connect your two or three most relevant business processes to their cloud costs.
Details
Start with the processes that drive spending
Connect your two or three most relevant business processes to their cloud costs.
Begin with the work your business needs to deliver: for example, processing orders, serving customers, or producing reports. Together, we select the two or three processes that matter most to the spending decision.
A business cost model connects activity to workloads, resource use, and charges. Its value driver tree makes those connections visible, so you can see why spending changes when business volume changes.
Example plan · Value driver tree
Example plan / Month 12 / USD
Select a component to follow its contribution to the cost.
01Researchers
58people running simulations
Simulation demand follows the hiring plan: 30 researchers at the start, 120 by month 36.
BasisThe company's hiring plan, agreed with Finance.
02Runs per researcher
19simulation runs / month
One burst run per researcher per working day. Most work stays on in-house machines.
BasisUsage pattern agreed with the engineering team.
03Node-hours
8,862node-hours / month
Runs multiplied by 8 node-hours each. The cluster runs only during jobs, 156 of 730 hours a month for one always-on node.
BasisScheduling replaces an always-on machine.
04Node-hour price
$7.58per node-hour, on demand
Arm instances cut the cost per simulation run from $0.62 to $0.22 in a benchmark.
BasisOne benchmark case. Results are specific to that simulation.
05Monthly compute cost
$67,127USD in month 12, before credits
Node-hours multiplied by price. Storage and the data platform add $26,969, for $94,096 on demand.
BasisProjected cost. Credits and commitments then reduce the cash paid.
Goes in
Business volume and plans, workload and billing evidence, existing obligations, and the agreed scope.
Comes out
An agreed baseline and a traceable cost model, with assumptions and evidence gaps visible.
Next, decide which savings tools this model is allowed to evaluate.
↓

Step 02

Choose permitted tools

Keep purchases and operational changes within your company's limits.

Details

Choose the tools your company permits

Keep purchases and operational changes within your company's limits.

Finance and Engineering agree which tools can be considered, where they can be used, and what limits apply. A tool enters the plan only when its permissions, eligibility, and prerequisites are satisfied.

Tool category	Financial question it answers
Commitments and optional protection	How much usage can we commit to, for how long, and with what cash exposure?
Storage policies	Which data can cost less to keep while meeting access and retention requirements?
ARM64 migration	Where would lower running costs justify compatibility work and implementation effort?
Spot with fallback	Which interruptible work can cost less while still meeting its completion requirements?

Goes in: Approved suppliers and methods, contract limits, service requirements, engineering capacity, and workload eligibility.
Comes out: Eligible candidate actions, with conditional actions and missing evidence identified.

Next, compare how these choices work together. Individual savings estimates cannot simply be added.

↓
Step 03
Simulate combined plans
Compare spending, cash needs, and service outcomes as demand changes.
Details
Test the combined plan before acting
Compare spending, cash needs, and service outcomes as demand changes.
Simulation compares candidate plans against the same demand scenarios and the same baseline. It includes the cost of making changes, obligations already incurred, and the way tools affect each other.
For example, moving work to a more efficient configuration can reduce the commitment you need to buy. We evaluate that sequence together, including what happens if demand falls or implementation takes longer.
“No new action” is a valid outcome. Simulation is evidence for a decision; it does not guarantee actual savings or technical feasibility.
Goes in
The cost model, eligible actions, demand scenarios, rollout assumptions, and financial and service limits.
Comes out
Comparable costs, savings, cash requirements, forecast ranges, and reasons to accept, defer, or reject each evaluated plan.
Next, turn the lowest-cost acceptable plan among those evaluated into a spending and action schedule.
↓
Step 04
Get your spending plan
See what to spend, what to change, and when each decision is due.
Details
Receive a plan Finance and Engineering can use
See what to spend, what to change, and when each decision is due.
Your plan links two schedules. The spending schedule shows expected costs, savings, forecast ranges, and payments over time. The action schedule names each purchase or operational change, its owner, its date, and the evidence required before it proceeds.
A decision summary brings together the recommendation, cash exposure, principal risks, and approvals needed.
Goes in
The selected candidate, assumptions, prerequisites, and comparison basis.
Comes out
A versioned spending and action plan for review. A recommendation remains pending until the relevant owners approve it.
Use the first iteration to assess a migration, or continue with weekly reviews for an existing platform. See the example plan
↓ Then choose your path
Outcome A · Initial setup
Validate a migration
Use the first iteration to assess the migration before committing.
⊣ Ends after the first reviewed iteration
Details
Validate the financial case for a cloud migration
Use the first iteration to assess the migration before committing.
The first dashboard brings together projected cloud spending, migration costs, cash timing, and the assumptions behind the proposed move. Compare the migration plan with the agreed alternative and see the evidence still needed to proceed.
This engagement ends with the first reviewed iteration and a decision: proceed, run a pilot, revise the plan, or defer. Continuing optimization can be scoped separately.
Goes in
The current or alternative operating plan, proposed cloud design, business demand, migration effort, and overlap costs.
Comes out
A first-iteration financial assessment and spending schedule supporting the migration decision, against an explicitly named baseline.
Boundary
Financial validation under stated assumptions. Technical validation still needs the relevant workload evidence or pilot.
The migration path stops here after review.
Request a review
or
Outcome B · Recurring setup
Improve every week
Refresh the plan weekly and see each spending change in context.
↺ Repeats weekly from step 01
Details
Review the existing platform every week
Refresh the plan weekly and see each spending change in context.
For optimization within the same technology solution, review the plan every week using the latest available demand, usage, prices, and implementation evidence. Recheck permitted actions and existing commitments, then compare the revised schedule with the previous version.
See which periods changed, by how much, and why. If the evidence supports keeping the current plan, the review records that result.
Goes in
The previous plan, new evidence, actual results where available, obligations, and current permissions.
Comes out
A dated review, a revised plan when needed, and a visual explanation of schedule changes.
Boundary
Weekly review does not mean weekly execution or approval of changes.
Refresh the affected inputs and permissions, rerun the comparison, and review the decision. See a version comparison
Request a review

02 / Your spending plan

See what you will spend, when to act, and what changed.#

Delivered plan · HPC startup in energy · Version 2

36-month plan between Series A and Series B

DeliveredAnonymized · USDFigures are projections

Spending schedule #

Monthly cash against the on-demand cost

On-demand costPlanned cashCredits cover the billCommitment purchase

What drives the cost #

36 months at on-demand prices · reconciles to the total

Burst runs on Arm instancesSimulation compute$3.06M70% of the on-demand cost
Analytics, model training, securityData platform and services$0.93M21% of the on-demand cost
Tiered from fast to archiveSimulation data storage$0.35M8% of the on-demand cost

Action schedule #

Each saving is tied to a dated action

Date	Action	Owner	Evidence before it proceeds	Approval
Before month 1	Move simulation runs to Arm instances	Engineering	A benchmark run costs $0.22 instead of $0.62.	Done
Before month 1	Run the cluster only during jobs	Engineering	Burst runs replace an always-on machine.	Done
Months 1–10	Use startup credits, then migration credits	Finance	The two credit programs cannot be combined, so they run in sequence.	Approved
Month 11	Buy a one-year commitment for 55% of forecast compute	CFO	Usage over the previous three months confirms the forecast.	Approved
Months 11–36	Cover 30% of compute with monthly commitments	FinOps	Resized each month against last month's usage.	Approved
Month 23	Buy the second one-year commitment	CFO	Sized from trailing usage, within 50% to 150% of forecast.	At month 22 review

Cost and cash schedule #

Projected · USD

Projected cost, credits, commitment savings, and cash by year and quarter over 36 months
Period	On demand	Credits	Commitment savings	Paid upfront	Cash out	Difference
Year 1Months 1–12	$757k	−$342k	−$29k	$296k	$633k	−$124k
Q1Months 1–3	$112k	−$112k	—	—	$0	−$112k
Q2Months 4–6	$155k	−$88k	—	—	$67k	−$88k
Q3Months 7–9	$224k	−$78k	—	—	$145k	−$78k
Q4Months 10–12	$266k	−$63k	−$29k	$296k	$421k	+$154k
Year 2Months 13–24	$1,466k	−$163k	−$201k	$461k	$1,238k	−$227k
Q1Months 13–15	$308k	−$65k	−$45k	—	$124k	−$184k
Q2Months 16–18	$346k	−$40k	−$47k	—	$186k	−$161k
Q3Months 19–21	$386k	−$28k	−$48k	—	$236k	−$150k
Q4Months 22–24	$426k	−$30k	−$61k	$461k	$693k	+$267k
Year 3Months 25–36	$2,116k	−$143k	−$252k	—	$1,336k	−$779k
Q1Months 25–27	$466k	−$33k	−$69k	—	$249k	−$218k
Q2Months 28–30	$508k	−$34k	−$70k	—	$288k	−$220k
Q3Months 31–33	$550k	−$35k	−$72k	—	$328k	−$222k
Q4Months 34–36	$592k	−$41k	−$41k	—	$472k	−$120k
Total	$4,339k	−$648k	−$482k	$757k	$3,208k	−$1,131k

A delivered plan for an HPC startup in energy, anonymized. Monthly figures are the plan's projections from its spend model; the forecast range is from simulated demand. The cost-per-run figure is from one benchmark and is specific to that simulation.

See what changed since the last plan.#

Compare the previous and current plans on the same basis. Every change shows the financial difference and the decision behind it.

v1 · Three-year commitment (dotted)v2 · One-year commitments (solid)Cumulative cash · USD

v1 previousv2 currentOwed after the plan

Plan history

Prior versions keep their original assumptions

v2 · Delivered · One-year commitments$3.21M · nothing owed after
v1 · First draft · Three-year commitment$2.70M + $938k after

What changed

3 decisions

Longest commitment · Explanation

Previous: 3 years
Current: 1 year

Why: The Series B was planned within the 36 months. A three-year term would have committed cash beyond the money already raised.
Effect: Commitments are bought for one year at a time, in months 11 and 23, and sized at 55% of forecast compute.

First iteration · Migration assessment

First plan. No previous version.

A migration engagement ends after this reviewed iteration with a decision: proceed, run a pilot, revise the plan, or defer. The comparison below is against the agreed baseline instead.

36 months	Amount
Cloud cost at on-demand prices	$4.34M
Planned cash after credits and commitments	$3.21M
Migration effort	Agreed during scoping
Overlap costs while both run	Agreed during scoping

Decision required

Proceed, pilot, revise, or defer the migration.

Baseline: Named explicitly. Migration savings and savings inside a proposed cloud design are different comparisons.
Cash dates: Shown once migration and overlap costs are agreed.
Boundary: Financial validation under stated assumptions. Technical validation needs workload evidence or a pilot.

Your plan uses your own business processes, permitted tools, funding timeline, and evidence.

Request a review

03 / Two engagement paths

Validate a migration. Or improve the plan every week.#

Initial cloud migration

Validate the financial case before committing.

The first plan brings together projected cloud spending, migration costs, cash timing, and the assumptions behind the proposed move, compared with the agreed alternative.

You receive: A first-iteration financial assessment and spending schedule.
Decision: Proceed, run a pilot, revise the plan, or defer.
Ends: After the first reviewed iteration. Ongoing optimization is scoped separately.

One iteration, then a decisionRequest a migration review

Existing technology solution

Review the plan every week.

Each week the plan is checked against the latest demand, usage, prices, and implementation evidence. You see which periods changed, by how much, and why.

You receive: A dated weekly review and a revised plan when the evidence supports one.
Decision: Approve, defer, or keep the current plan. Weekly review is not weekly purchasing.
Repeats: Every week, with monthly spending periods and invoice reconciliation.

Weekly loopRequest a weekly review

04 / Short answers

Questions Finance asks first.#

Will savings compromise service?

Plans are evaluated against the service requirements you agree with Engineering. Changes that fail those limits are excluded or stay pending for evidence.

How much work is required from our team?

Start with two or three relevant processes and the evidence already available. We identify missing measurements, pilots, owners, and effort before recommending implementation.

Will you make purchases or changes automatically?

No. The plan identifies what needs approval. Finance and Engineering retain control over purchases and operational changes.

What if demand changes?

The forecast shows a range. For ongoing optimization, weekly reviews update assumptions and show how the spending schedule changes.

What if the savings are smaller than expected?

The review establishes what the evidence supports after costs and constraints. The result may be a smaller saving, a pilot, a deferred action, or keeping the current plan.

What do we need to begin?

A cloud spending objective, the processes driving that spend, and a Finance or Engineering contact. Detailed billing, workload, and commitment data requirements are agreed during scoping.

Request a review

Start with your next cloud spending decision.#

Tell us whether you are planning a migration or improving an existing platform. We will agree the scope and evidence needed for your first plan.

Scope the two or three processes
Agree evidence and permitted methods
Prepare the first plan
Review the decision together

Closed beta. Invited customers receive a private workspace for their engagement.

Optimize your cloud spend.A spending schedule with no surprises.

From your business activity to a spending plan.#

Model 2–3 key processes

Start with the processes that drive spending

Choose permitted tools

Choose the tools your company permits

Simulate combined plans

Test the combined plan before acting

Get your spending plan

Receive a plan Finance and Engineering can use

Validate a migration

Validate the financial case for a cloud migration

Improve every week

Review the existing platform every week