Shipping AI
How to price an AI project when you can’t promise accuracy
Fixed-price assumes a known scope. Machine learning does not give you one up front. A structure that protects both sides without pretending.
5 min readByteWeave Studio
A client asks what it costs to automate their invoice processing. The honest answer on day one is that nobody knows, because the cost depends on how messy their documents are and neither party has looked yet. The unhelpful answer is to say that out loud and leave.
Fixed-price contracts assume the scope is knowable in advance. Time and materials shifts all the risk onto the client and gives them no ceiling. Most AI work sits awkwardly between the two, and pretending otherwise is how projects end in a dispute.
Sell the assessment separately
Split a small, fixed-price first phase whose only deliverable is knowing what the real project costs. Two to three weeks, priced so it is an easy yes. You take a genuine sample of their data, run it through a baseline, and report what accuracy looks like, where it fails, and what it would take to close the gap.
This is not a sales trick. It is the only point where an accuracy estimate can be made responsibly, and the client ends up owning something useful even if they stop there — a characterisation of their own data that they did not have before.
Quote the workflow, not the model
Accuracy is uncertain. The rest of the system is not. Ingestion, the review interface, integration with the accounting system, deployment, monitoring and handover are ordinary software with ordinary estimates, and on most document projects they are the larger share of the work.
Price those normally and fixed. Then treat model improvement as a separate, bounded track with a target and a stopping rule. The client sees a firm number for the system and a capped number for the part that is genuinely uncertain.
Write the acceptance criterion in their terms
Avoid accepting on a raw accuracy figure. It invites arguments about which documents count, and it does not describe anything the client cares about. Write it as throughput instead: the share of documents that complete without human intervention, at an error rate below an agreed threshold, measured on their intake rather than a sample you chose.
Agree the measurement method before work starts, including who keys the ground truth and what happens to documents both parties consider unreadable. Most acceptance disputes we have seen were disagreements about measurement, not about the system.
Say what happens after handover
Models drift because the world moves — vendors change templates, a new business unit joins with different paperwork, someone replaces the scanner. A project priced as though it ends at go-live is priced wrong, and the client discovers this six months later when accuracy has quietly slipped.
Put a support arrangement in the original quote rather than as an afterthought: a monitoring dashboard, an agreed review cadence, and a retraining allowance. It is easier to sell as part of the plan than as a rescue.
- Consulting
- Pricing
- Project scoping
More reading
Shipping AI
What actually breaks in a production ML system
It is almost never the model weights. Four failure modes we keep meeting, and the monitoring that catches each one.
5 min read
Shipping AI
Human-in-the-loop design: deciding when to ask a person
Route too much to review and you have rebuilt the manual process. Route too little and people stop trusting the output. Where the line goes.
5 min read
Document AI
Why your invoice OCR works in testing and fails in production
The test folder is clean exports. The real intake is phone photographs. What changes between the two, and how to find out before a client does.
5 min read
Have a problem
worth solving?
Tell us what you're building. We'll help you figure out what's possible — and say so if we're not the right people for it.