How to estimate an AI project honestly: ranges, phases and the costs people forget

“How much will it cost, and how long will it take?” is the first question on every project, and the hardest one to answer honestly. Ordinary software can often be estimated from experience. AI work contains a different kind of unknown: until you try, you do not know whether your data is good enough, how accurate a model can become or how much effort the last ten percent of quality will take.

This does not mean estimates are useless. It means they must be built differently. Here is how we approach it, and what clients can do to get a number they can trust.

Why a single fixed price is risky

A fixed price for a whole AI project forces someone to guess the unknowns. If the supplier guesses low, they will cut corners or run out of money. If they guess high, the client overpays for risk that may never appear. Either way, the incentives are poor. The uncertainty is real, and pretending otherwise just hides it.

Estimate in phases

A better approach is to divide the project into stages, with a clear result and a decision after each. The early phases are small and fixed. Later ones are estimated as ranges that firm up as you learn.

1. 01Discovery (days to two weeks): clarify the decision, users, data and success measure. Result: a one-page scope and an honest feasibility view.
2. 02Proof of concept (four to eight weeks): test the core idea on a small slice of real data. Result: evidence of what accuracy is realistic, and a refined estimate.
3. 03Build (a range): develop the full solution, with integration, interface, security and testing.
4. 04Pilot with users (four to eight weeks): run it in the real setting, and measure against the baseline.
5. 05Rollout and handover: train people, document the system and agree who maintains it.

The first two phases are inexpensive, and they buy the information that makes the later estimates reliable.

Give ranges, and say what moves them

An honest estimate sounds like: “Between X and Y, most likely near the middle. It will be at the high end if the data needs more cleaning than the sample suggests, or if integration with your existing system is harder than expected.” That is more useful than a single number, because it tells you where to look for risk.

• Ask for the assumptions behind every estimate.
• Ask what would make it higher, and what would make it lower.
• Agree how you will handle changes, so that small ones do not become disputes.

The costs people forget

The model is often the smaller part of the budget. These are the items that most often go missing.

• Data preparation. Finding, cleaning, joining and documenting data is frequently the biggest single item.
• Labelling. Supervised models need examples of the right answer, and creating them takes expert time.
• Testing and evaluation. Building a good test set, running it and fixing what it finds is real work.
• Integration. Connecting to existing systems, logins, databases and workflows is slow, and full of surprises.
• Interface and design. Even a good model needs a screen that people can understand and trust.
• Security and privacy review. Especially with personal or sensitive data.
• Training and change management. People need to learn and want to use the system.
• Running costs. Cloud computing, storage, model usage fees, licences and monitoring continue after delivery.
• Maintenance. Models and data age, so budget for upkeep every year.

Questions to ask a supplier about their quote

• What phases is the work divided into, and what do I get at the end of each?
• What is included, and what is explicitly excluded?
• What assumptions about data, access and people does the estimate rely on?
• What happens if the first phase shows that the idea will not work?
• Who owns the code, the models and the data?
• What will it cost to run each month after launch?
• How are changes handled, and how are they priced?

Reducing risk on the client side

• Name an owner with time and authority, and make decisions quickly. Waiting for approvals is the commonest source of delay.
• Give access to data and people in the first week.
• Agree the success measure and baseline early.
• Review progress with real users, not only with managers.
• Be ready to stop or change direction when the evidence says so.

A worked example

A tourism board wants an AI assistant that answers visitor questions from its documents. A single quote would have to guess the quality of those documents. Instead, the work is phased. Discovery takes a week: it finds that documents are mostly current but scattered, and defines 50 sample questions. A four-week proof of concept shows that 80 percent of questions are answered correctly, with a few document gaps that the board can fill. Build is then estimated as a narrower range, including a staff review screen and monthly document updates. The pilot runs in one visitor centre for six weeks, and the board decides to roll out only after comparing answers with its baseline. Nobody was surprised, because the uncertainty was reduced step by step.

Mistakes that blow budgets

• Treating the first demonstration as proof that the full system is nearly finished.
• Skipping discovery, to “save time”.
• Letting scope grow without adjusting time or money.
• Leaving integration and security for the end.
• Choosing the lowest price without checking what it leaves out.

Frequently asked questions

Can we still have a fixed price?

Yes, for the well-defined phases such as discovery and a proof of concept. For later phases, a range or a capped time-and-materials arrangement is usually fairer for both sides.

How accurate is an estimate after discovery?

Much better than before. It usually narrows to a range that can be defended, with named assumptions.

What if the proof of concept fails?

Then you have spent a small amount to learn that, which is a good outcome. You can change the approach, fix the data or stop.

How do we compare quotes?

Compare what is included, the phases, the assumptions and the running costs, not just the headline price.

An honest estimate admits what is not yet known and shows how it will be found out. That may feel less comforting than a single confident number, but it is far more likely to match what the project truly costs, and far less likely to end in an argument.