Can an AI project be fixed price? Only after discovery

Not the build, and yes the discovery. Fixed price requires knowing what correct looks like before work starts, and on an AI project that knowledge is the output of the first phase rather than an input to it. Fix the price of discovery, and let it produce the evidence a build number can stand on.

JarvisBitz

Procurement wants a fixed price, and the reason is entirely legitimate: a number you can approve, a scope somebody else is accountable for, and no open ended invoice. Every buyer asking for this is doing their job.

The honest answer is that the build usually cannot be fixed price, the discovery can and should be, and a vendor who quotes a fixed number for the whole thing before seeing your data is either padding heavily or planning to argue about scope later.

What fixed price actually requires

A consulting guide from May 2026 sets out the conditions plainly, and they are worth reading as a checklist rather than a caveat. Fixed price works when "requirements are fully documented" with acceptance criteria and edge cases defined before work begins, when "data is available and understood" and labelled with its quality assessed, when the "technology stack is proven" with no research risk, and when "scope change expectations are zero". All four have to hold at once, and where they do not, fixed pricing "transfers risk in ways that typically damage project outcomes".

Read those four against a typical AI build and the problem is obvious. Nobody can define acceptance criteria for an extraction system before anyone has looked at the documents, because the criteria depend on what the documents turn out to contain. That is not a preparation failure. The information does not exist yet.

The specific thing that is unknown

Ordinary software has uncertainty about effort. AI builds have uncertainty about whether the approach works at all on your data, and those are different risks that get priced the same way by mistake.

A team quoting for a checkout flow knows it can be built. The question is how many days. A team quoting to classify your support tickets to ninety percent accuracy does not know whether ninety percent is achievable on your tickets, because it depends on how consistently your categories have been applied historically, which nobody has measured.

What discovery has to produce

Fix the price of a short discovery instead, and hold it to concrete outputs rather than a report. Three deliverables make a subsequent build number honest.

• An evaluation set from your real data, with correct answers recorded by someone who knows the domain. This is the artifact everything else depends on, and it is the one you should own outright.
• A measured baseline. What the current process achieves and costs. Without it nobody can tell later whether the system helped, which is how projects end without a verdict.
• A tested approach against that set, so the quote rests on an observed number rather than an assumed one.

Discovery of this shape is genuinely fixed priceable, because the effort is bounded and the deliverables are defined. Two to four weeks is typical. And it is useful independently: if the answer is that the approach does not work on your data, you have learned that for the cost of a few weeks rather than a programme.

What to fix price after discovery

Once an evaluation set exists, several things become fixable that were not before, and it is worth asking for them specifically.

• A target on the evaluation set, with a defined remedy if it is missed. This is the closest thing to a fixed outcome available, and it only exists because discovery produced the measure.
• Integration work, which is ordinary engineering once the interfaces are known and prices like ordinary engineering.
• The deployment and handover, including the artifacts that transfer.
• Ongoing support, as a rate rather than a project, which we cover in what maintenance actually involves.

What stays variable is the modelling work between having a measure and hitting it, because that is the part where nobody can promise how many attempts it takes. Capping it is reasonable. Fixing it is fiction.

The questions worth asking a vendor

A useful test of whether a fixed price is honest or padded, in three questions.

• What did you assume about our data to produce this number, and what happens to the price if the assumption is wrong? A good answer names specific assumptions. A vague one means the risk premium is doing the work.
• How will we both know it worked? If there is no agreed measure, fixed price is fixed effort with an argument at the end.
• What would make you come back and ask for more? Everyone has a threshold. A vendor who says nothing would is either not planning to tell you until it happens or has priced defensively.

None of this is an argument for open ended spending. It is an argument for spending a small fixed amount to buy the information that makes a larger number meaningful, which is also the cheapest way to find out that you should not proceed. We set out what drives the eventual figure in what custom AI development costs, and how we structure the stages in our engagement model. A free AI audit is a reasonable way to find out whether your data supports the thing you want quoted.

Related reading

AI vendor security questions: what a good answer sounds like

The standard questionnaire will not tell you what you need. SOC 2 covers how a vendor runs their own company, not what the agent they build for you is able to do when it is talked into the wrong action. The questions that separate a serious builder are about permissions, credentials, and what capability they gave up to get there.

Build vs buy an AI agent: the arithmetic that decides it

You cannot answer it until you know how many billable actions one conversation takes, because every pricing model now meters actions rather than conversations. That makes your bill a consequence of how the agent is designed, and it means the same use case can land either side of the line depending on choices you have not made yet.

What you should own when the AI build ends

The code is the least valuable thing you funded. Name the prompts, the eval set, the embeddings and index configuration, the fine-tuned weights if any, and the infrastructure definition, in usable formats. The eval set matters most, because it is the artifact a successor cannot cheaply rebuild.