The Estimate Ships With the Build
Alchemist AI Pro™ · Deterministic Estimation
The Estimate Ships With the Build
How Alchemist AI Pro™ turns every estimate into a reproducible, version-controlled computation.
James "Jamie" Campbell · Product Owner, Alchemist AI Pro™ · ACC3 International / AI Pro Holdings · August 2026
Every software estimate I encountered in twenty-five years of enterprise delivery was an argument. Someone senior produced a number, someone commercial adjusted it, and someone accountable spent the next year explaining the difference. The number was an opinion before it was anything else, and opinions bend under incentive.
This is how our builds are estimated now, because the method makes a claim most of this industry has quietly given up on: an estimate can be a computation. Derived from the requirements, by a fixed formula, producing the same number every time the same inputs go in. No optimism baked in. No sandbagging. Nothing to negotiate.
Where the Number Comes From
A mechanical count, driven entirely by the structure of the requirements
When a requirements package leaves Alchemist AI Pro™ and enters the Alchemy Crew, the build designer counts the work before any of it starts:
Setup
A small, fixed set of tasks — project planning and scaffolding, adjusted for the technology stack.
Per feature
Eleven fixed tasks for every feature — database design, interface design, integration checks, testing, documentation among them.
Backend, per use case
Four fixed tasks — model, API, read path, business logic.
Frontend, per use case
Three tasks for every use case that carries an interface — the classifier that decides which ones do is itself part of the codebase, applied the same way every time.
Closing quality pass
Security review, dependency scanning, integration verification, deployment.
Each task category carries a fixed story-point weight, set to approximate what the task costs a manual development team — a setup task is 8 points, a backend use-case task is 5. The full weight table is published with every estimate. Two conversions finish the job: one story point is four hours of manual development effort, and forty points make one team-week.
That's the entire method. It has a name in the codebase — the deterministic task formula — and a defining property: rerun it a hundred times against the same requirements and it produces the same number a hundred times. The estimate cannot be talked up or talked down, because there is no one to talk to.
Where the Estimate Lives
The part I find most useful
The moment a build's first task completes, the system writes the estimate into the application's own repository — a file named estimate.md, sitting beside the project plan, carrying the summary, the formula inputs, and the full story-point breakdown, under a timestamped commit. The footer on every one of them reads: deterministic estimate — same inputs always produce the same number.
The estimate is no longer a slide from a kickoff meeting that nobody can find by month three. It is version-controlled evidence, born with the code it describes, and it never drifts, because it never changes unless the requirements do.
It also means the estimator is accountable. Projected task counts sit in the record next to executed task counts, build after build. Most estimation methods never face that comparison. Ours cannot avoid it.
A Worked Example, With the Receipts
The AI Pro CRM rebuild — 13 features, 105 use cases
The formula produced 2,978 story points from the CRM rebuild's requirements. Check the arithmetic yourself from the numbers on this page: 2,978 × 4 is 11,912; 2,978 ÷ 40 rounds to 74.5.
2,978
Story Points
Projected across 809 formula-derived tasks.
11,912
Estimated Hours
Manual development effort at 4 hours per point.
74.5
Team-Weeks
At forty points per team-week.
748
Tasks Executed
By the automated Crew build, in roughly two days.
61.8
Final-Mile Hours
Human hours tracked — about 35 minutes per use case.
104/105
Use Cases Delivered
The application runs our own sales pipeline in production today.
74.5 estimated weeks against a build measured in days and a human contribution measured in hours. The estimate side of that ledger is the formula's stored output for this exact workflow — recomputable by anyone who holds the requirements. That is what separates a receipt from a brag.
We Checked the Code Before Writing This
Traceability is the standard we sell, so it is the standard this paper had to meet. Before writing, we walked the estimator's source: the counting logic, the weight constants, the conversion multipliers, and the code path that pushes estimate.md into each repository. The published CRM figures reproduce exactly from the stored formula.
We also found one cosmetic defect — a display row in the rendered breakdown table that shows a retired weight — and filed it. The totals are computed from the current weights and are correct; the row will be fixed so that a skeptical reader's re-addition matches to the point.
A verification that only ever confirms is not a verification.
What This Asks of the Requirements
A formula this literal has a dependency, and it is the same dependency everything in our lifecycle has: the requirements. The census counts features and use cases; the classifier reads each use case to decide what it needs. Hand the formula vague requirements and it will faithfully estimate the wrong application. Hand it hyper-defined requirements — every use case explicit, every interface decision stated — and the estimate becomes what an estimate should have been all along: a property of the specification, measured, repeatable, and attached to the work for the life of the system.
Good requirements buy speed, but not without guardrails. The estimate, it turns out, is one of the guardrails.
Next Step
The AI Pro CRM build record — including the estimate, the task counts, and the final-mile hours — is documented in our library.
Questions belong at jamie@acc3int.com.