# OpexOpt

> 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.

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

OpexOpt is a Datadeft Kft. product. It is in closed beta, and access to customer workspaces is by invitation.

## How it works

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

1. Start with the processes that drive spending: Connect your two or three most relevant business processes to their cloud costs. Input: Business volume and plans, workload and billing evidence, existing obligations, and the agreed scope. Output: An agreed baseline and a traceable cost model, with assumptions and evidence gaps visible.
2. Choose the tools your company permits: Keep purchases and operational changes within your company's limits. Input: Approved suppliers and methods, contract limits, service requirements, engineering capacity, and workload eligibility. Output: Eligible candidate actions, with conditional actions and missing evidence identified.
3. Test the combined plan before acting: Compare spending, cash needs, and service outcomes as demand changes. Input: The cost model, eligible actions, demand scenarios, rollout assumptions, and financial and service limits. Output: Comparable costs, savings, cash requirements, forecast ranges, and reasons to accept, defer, or reject each evaluated plan.
4. Receive a plan Finance and Engineering can use: See what to spend, what to change, and when each decision is due. Input: The selected candidate, assumptions, prerequisites, and comparison basis. Output: A versioned spending and action plan for review. A recommendation remains pending until the relevant owners approve it.

After step 4 there are two engagement outcomes:

- Outcome A · Initial setup. Validate the financial case for a cloud migration: Use the first iteration to assess the migration before committing. Financial validation under stated assumptions. Technical validation still needs the relevant workload evidence or pilot.
- Outcome B · Recurring setup. Review the existing platform every week: Refresh the plan weekly and see each spending change in context. Weekly review does not mean weekly execution or approval of changes.

## Savings tools a company can permit

- 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?

## What the plan contains

- A spending schedule: expected monthly costs, savings, and forecast ranges against an agreed baseline.
- An action schedule: each purchase or change with its date, owner, evidence required, and approval status.
- A cash schedule: payments over time, including upfront requirements.
- A decision summary: recommendation, cash exposure, principal risks, approvals needed, and what changed since the last version.

## Example plan

A delivered plan for an HPC startup in energy, anonymized, between its Series A and Series B. Figures are the plan's projections over 36 months.

- Cloud cost at on-demand prices: $4.34M. Planned cash: $3.21M, 26% lower.
- Forecast range for cash: $2.7M to $3.8M (10th to 90th percentile of simulated demand).
- Startup and migration credits cover months 1 to 10. One-year commitments are bought in months 11 and 23, covering 55% of forecast compute; nothing is owed after the plan ends.
- An earlier version recommended a three-year commitment. It was replaced because it would have left $938k owed beyond the funding already raised.
- Arm instances cut the cost per simulation run from $0.62 to $0.22 in one benchmark; this figure is specific to that simulation.

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

## Questions

### 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

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.

1. Scope the two or three processes
2. Agree evidence and permitted methods
3. Prepare the first plan
4. Review the decision together

- Email: hello@opexopt.eu
- Website: https://www.opexopt.eu/

## Main pages

- [Homepage](https://www.opexopt.eu/): how OpexOpt plans cloud spending, an example plan, and how to request a review.
- [Privacy notice](https://www.opexopt.eu/privacy/): What personal data the OpexOpt website and review requests involve, why, for how long, and your rights.
- [Legal notice](https://www.opexopt.eu/legal/): Company registration, contact, and hosting information for the OpexOpt website.

## Publisher

Datadeft Korlátolt Felelősségű Társaság (Datadeft Kft.), 2473 Vál, Barack dűlő 49., Hungary. EU VAT: HU29306862. https://www.datadeft.eu