You ask three vendors what it will cost to add document understanding to your product. One says $40,000, one says $95,000, one says "it depends" and asks for a call. The first two sound confident. The third sounds evasive. In our experience the third is usually the only one that has done this before.
AI features have a cost shape that ordinary features do not. A login screen is roughly the same job for everyone who builds one. An AI feature depends on a thing nobody can inspect from a requirements document: how your real inputs behave. A quote that does not mention this is either padded heavily or written by someone who has not yet been burned.
This is not an argument against fixed budgets. It is an argument for knowing which parts of an AI estimate are firm and which are a range, so you can stage the spend instead of betting all of it on a guess.
The firm part and the soft part
Split any AI feature estimate into two halves and ask the vendor to price them separately.
- The surrounding product work. Screens, permissions, storage, queues, billing hooks, admin tooling, review interfaces. This is normal software and can be estimated normally.
- The model-dependent work. Getting accuracy to a level your users will accept, handling the odd inputs, tuning retrieval or prompts, deciding where a human reviews. This is the part that has a wide range, because it depends on data nobody has measured yet.
When a quote presents one number for both, the soft half is hiding inside the firm half. You will find out which it was when accuracy lands short and the vendor either absorbs the loss and cuts corners, or opens a change request.
What widens the range
These are the factors that move an AI estimate most, roughly in order of how often they surprise people:
- Input variety. Ten clean PDFs from one supplier and ten thousand files from forty suppliers are different projects. Scans, handwriting, rotated pages and mixed languages each add work.
- The accuracy bar. Getting from "mostly right" to "right enough to act on without checking" is where cost climbs sharply. If a human reviews everything anyway, the bar is lower and the budget is smaller.
- Cost of a wrong answer. A mistaken suggestion in a drafting tool is a nuisance. A wrong number in a bid or an invoice is a loss. The latter needs confidence scoring, review flows and audit trails.
- Ground truth. If you have a few hundred correctly labeled examples, the work can be measured. If you do not, part of the budget goes to creating them.
- Running cost. Per-call model costs scale with usage. This belongs in the operating budget, not the build quote, but it should be modeled before launch so that pricing your own product does not become a surprise.
Buy information first: the paid spike
The cheapest way to narrow a range is a small, time-boxed spike on your own data. Typically that means a week or two of work with a fixed fee, producing one thing: a measured answer to "how well does this work on our real inputs, and what would it take to improve it?"
A good spike hands you three artifacts: a sample of results on your files with the failures shown, a rough accuracy figure computed against examples you agree are correct, and a revised estimate for the full build with a narrower range. If the spike shows the idea does not work well enough, you have spent a small amount to learn that, which is a good outcome.
Be careful with free demos. A demo on the vendor's chosen examples tells you the vendor can pick examples. We cover how to design a test that actually discriminates in how to run a vendor pilot that works.
How to read the quotes you get
Some questions that separate a considered estimate from a hopeful one:
- Does the quote say what accuracy it assumes, and how it will be measured?
- Is there a line for evaluation, or is testing assumed to be free?
- What happens to the budget if the first approach does not reach the bar?
- Does it separate build cost from per-use model cost?
- Does it describe how uncertain outputs get routed to a person?
A vendor that answers these specifically has probably shipped the thing. For a sense of what real review design looks like, see human-in-the-loop review design. Our own experience includes vision-model takeoff with per-line confidence scores directing human review, which is the pattern behind BuildAEC, and it is the reason we price review flows as part of the feature rather than as an extra.
When a single fixed price is fine
Not every AI feature needs a range. If the task is narrow, the inputs are uniform and a wrong answer is cheap, such as classifying support tickets into six known categories, a fixed price is reasonable and a spike may be unnecessary. The same goes for features built on well-trodden patterns where the vendor has measured the outcome on similar data before. The advice here applies most when your data is messy, your tolerance for error is low, or you have never run this kind of feature before.
A range also has a downside: it is harder to put in a budget spreadsheet. A workable compromise is to approve the spike as a fixed amount, then approve the build with a stated cap and a checkpoint at the halfway mark where you decide whether to continue. This mirrors how we describe staged engagements on our approach page.
What to do this week
- Collect 100 to 300 real inputs, including the ugly ones.
- Write down what a correct output looks like for a sample of them.
- State the cost of a wrong answer in dollars or hours.
- Ask each vendor to price the product work and the model-dependent work separately.
- Fund a short spike before funding the build.
If you want a second opinion on a quote you already have, send it over and we will tell you which lines look firm and which look soft.
Frequently asked
Why can't a vendor give a fixed price for an AI feature?
They can for narrow, well-understood tasks. For messy inputs or high accuracy needs, cost depends on how your real data behaves, which nobody knows until it is tested. A fixed price then either pads heavily for that risk or leaves you exposed to change requests later.
What is a paid spike and how long should it take?
A small, time-boxed piece of work, often one to two weeks, that tests the feature on your real inputs. It produces measured results, the failure cases and a narrower estimate for the full build, so you decide with evidence instead of a vendor's optimism.
Does the model usage cost belong in the build quote?
No. Per-call model cost scales with how much your customers use the feature, so it belongs in the operating budget. It should still be modeled before launch so your own pricing covers it, and the quote should state its assumptions about volume.
Is a free demo a reasonable way to compare vendors?
Rarely. A demo on examples the vendor chose shows the best case. A fairer comparison gives every vendor the same set of your messy inputs and the same definition of correct, then compares measured results and how each handles the failures.