How to Estimate an AI Project Without Guessing

AI estimates go wrong for a structural reason: part of the work is discovery, and discovery cannot be estimated. This playbook covers separating the two and producing a number that holds, drawing on FISTA Solutions' forward deployed engineers work.

When is this worth doing?

Before committing to a delivery date or a budget, and again after any discovery phase completes.

It is not worth doing in detail for a two-week experiment. The effort is justified when the number becomes a commitment somebody will be held to.

What does the sequence look like?

Step	Purpose
1. Separate known from discovered	Two different kinds of work
2. Timebox the discovery	With a decision at the end
3. List the integrations	Each one, with its failure modes
4. Add the operational work	Evaluation, monitoring, escalation
5. Estimate in ranges	With assumptions stated
6. Re-estimate after discovery	When unknowns become knowns

Step 1 — Separate known engineering from discovery

Known engineering: building the interface, wiring the integrations, deploying, monitoring. Those are estimable from experience.

Discovery: whether the model performs well enough on your data, whether retrieval finds what it needs, whether the workflow can be defined precisely. Those are not.

Mixing them produces an estimate whose largest component is a guess. Separating them lets you estimate the estimable part properly and handle the rest honestly.

Step 2 — Timebox the discovery

Two to four weeks to establish whether the approach works, with a stated decision point and criteria.

That is a commitment you can keep. It also produces the information that makes the rest of the estimate meaningful, which is why it belongs first rather than folded in.

Say what the discovery will establish and what result would mean stopping. A discovery phase with no failure condition becomes an indefinite build. See how to run an ai proof-of-value.

Step 3 — List the integrations individually

Every system the solution reads from or writes to, with authentication, data formats, rate limits, failure modes, and who owns it.

Estimate each separately. A list of six integrations estimated individually produces a credible number; a line item saying integration produces an optimistic one.

Include the systems whose owners you have not yet spoken to. Those carry schedule risk beyond their engineering effort, and naming them makes the risk visible.

Step 4 — Add the operational work

Evaluation infrastructure, monitoring, escalation paths, documentation, runbooks, and the review capacity the system will require.

These are the difference between a demonstration and something operable, and they are routinely absent from estimates because they are not features. Including them is what makes the estimate match what actually has to happen before launch.

As a rough guide, expect them to be a substantial fraction of the build rather than a rounding error.

Step 5 — Estimate in ranges with assumptions

Give a low, expected, and high figure, with the assumptions producing each and the two or three factors that would move it most.

Ranges are honest and more defensible. A range that held is a good estimate; a point that missed is a bad one, and the second is what single numbers reliably produce.

Name the assumptions explicitly: data quality, integration cooperation, approval timelines, and availability of the person who defines correctness. Those are where estimates actually break.

Step 6 — Re-estimate after discovery

When discovery completes, revise the estimate with what is now known and say what changed.

An estimate made before discovery and never revised is a commitment to a guess. Revising it is normal practice and it is considerably better received when it was expected.

Say that at the start: this is an estimate for the discovery phase, and the delivery estimate follows it. Stakeholders accept that structure when it is stated in advance.

How do you handle pressure for a single number?

Give the range and the expected figure, and be clear that the expected one assumes the stated conditions.

Giving in and providing a point estimate under pressure transfers the risk to whoever delivers it, and it removes the information that would have let the sponsor make a better decision.

Where a commitment is genuinely required, commit to the discovery phase with a decision point rather than to the whole thing.

What about fixed-price arrangements?

They work for the estimable part and poorly for discovery. A fixed price on a discovery phase is reasonable; a fixed price on delivery before discovery is a bet by one party or both.

The workable structure is a fixed-price discovery producing a fixed-price delivery estimate. Both parties get certainty where certainty is available, and neither is guessing about the part that cannot be known yet. See how to write ai acceptance criteria.

Who needs to be involved?

An engineer who has built something comparable, someone who knows the integration landscape, and whoever will be held to the number.

Estimates produced without the integration knowledge are optimistic by a predictable margin, because integration is where the unknowns concentrate.

How long does it take?

A few days for a scoped estimate once the requirements exist, plus the discovery period itself before the delivery estimate is meaningful.

What are the common failure modes?

Folding discovery into delivery. A single integration line item. Omitting evaluation and operations. Point estimates. Pressure-driven commitments. And never re-estimating.

How do you know it worked?

Delivery landing within the stated range, variances attributable to a named assumption, and stakeholders who expected the re-estimate rather than being surprised by it.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Separate your current estimate into what you know how to build and what you would be finding out. If the second is large, timebox it before committing to anything else.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: discovery timeboxed with a decision point rather than folded into a delivery estimate, integration sized per system rather than as a single line, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to run an AI proof-of-value.