Stage 1 — Estimate
When this stage runs
At project intake, before the first commit. The people in the room are the product owner and, usually, an architect. No engineer needs to be present, and nothing needs to exist in a repository.
Estimating happens inside the data product, not beside it. You create the product first — a name and a repository is all it takes — and the platform hands you straight to the estimator. There is no linking step and no orphan estimate waiting to be adopted by the right product.
What the estimator asks
The estimator is a conversation, not a form, because the useful questions depend on the answers to the previous ones. A migration is priced from what already exists; a greenfield build is priced from volumes and refresh rates. It works through:
- Shape of the work — migration, greenfield, or optimization of something running today.
- Data volumes and growth — how much lands per day, how much is retained, how fast it grows.
- Pipelines and refresh — how many, batch or streaming, how often each runs.
- Consumption — how many users query it, through what, how often.
- Build effort — the one-off cost of getting to production, separate from the recurring cost of running it.
Answers are grounded against current Databricks and Azure list prices rather than a static table, so an estimate produced today reflects today's rates. The conversation is stored with the estimate. Six months later, when the figure looks wrong, the assumptions that produced it are still readable.
Why an estimate carries two figures
A single number implies a confidence nobody has. Every Finowl estimate produces two.
| FIGURE | MEANING | USE |
|---|---|---|
| P50 | The midpoint. Actual cost is as likely to land above it as below. | Planning and comparison. This is the honest expectation. |
| P80 | Sufficient in about 80% of the modelled outcomes. | The budget. This is what Finowl proposes when you commit. |
The budget is the P80 for one reason: a budget set at the midpoint is under-funded half the time. A P50 budget is not a tight budget, it is a budget that will be breached on a coin flip, and a control that fires on half of all healthy projects trains everyone to ignore it.
The P80 is the P50 plus a published margin — 25% by default. Both figures freeze with the estimate. Changing the default margin later cannot move a budget somebody already agreed to.
Estimates you already have
Not every figure comes from the estimator. A number from a spreadsheet, a signed statement of work, or a previous project can be entered by hand. From that point it behaves identically: it can be committed, superseded, and compared against actuals.
This matters more than it sounds. The alternative is a product with no baseline because its number lives somewhere Finowl cannot read, and a product with no baseline is invisible to every cost control downstream.
Versions
Estimates are versioned. Re-estimating produces a new one rather than editing the old, so the record of what was believed at each point survives.
- Version 1 is created at intake and committed. It becomes the baseline.
- Scope changes. A new estimate is produced, reflecting what is now known rather than what was guessed.
- Committing version 2 supersedes version 1. The old figure is kept, marked superseded, and carries the reason it was replaced.
estimation.version in finowl.yml is accepted and ignored. The budget a run is checked against is fetched from the platform by product id, so it moved the moment a new estimate was agreed and never waited on a number in a file.What this stage does not do
The estimate is never enforced. Nothing blocks a merge for drifting from the baseline estimate, and the CLI does not compare a run against it. What gets enforced is the budget, and the budget only exists after Commit.