The Estimate Ships With the Build

How Alchemist AI Pro™ turns every estimate into a reproducible, version-controlled computation — with the AI Pro CRM rebuild as the worked example, receipts included.

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.

Read the CRM build record

Questions belong at jamie@acc3int.com.

About the Author

Jamie Campbell

Product Owner, Alchemist AI Pro™ · ACC3 International

With over 25 years of enterprise application experience, Jamie Campbell is a digital transformation expert who specializes in driving end-to-end SDLC modernization. He acts as a strategic agent of change, leveraging best-in-class digital process automation and Agile methodologies to deliver major business transformations.

View on LinkedIn Contact Jamie Campbell