DEV Community

Cover image for How to Scope AI Work When the Client Wants One Fixed Price
Sonal Jain
Sonal Jain

Posted on

How to Scope AI Work When the Client Wants One Fixed Price

Fixed price and artificial intelligence make an awkward pair. A fixed price wants certainty. AI work, especially the first version, carries real unknowns about data quality, accuracy, and how people will actually use the thing. Pretending those unknowns away to win a clean number is how projects quietly go underwater. I have watched it happen to good teams.

You can still commit to a fixed price. You just have to scope as if the unknowns are real, because they are.

Draw the box before you price the work

Before anyone talks money, I get almost fussy about the boundary. What goes in, what stays out, and where the edges sit. For an AI feature that means naming the exact inputs, the exact outputs, and the specific situations the system is responsible for. 'Answer customer emails' is not a scope. 'Draft replies for the eight most common order-status questions, in English, for a human to approve before sending' is a scope I can actually size.

The narrower and more concrete the box, the safer a fixed price becomes. Vague scope is where the money leaks out. So I spend real time here, and I pull the client into it instead of guessing on their behalf.

Phase the risky parts, commit the safe parts

Not every part of an AI project carries the same risk. Building the interface, the workflow, the human review step: fairly predictable. Getting a model to hit a certain accuracy on messy real-world data: much less so. I refuse to price those two things as if they were the same.

So I split the work. The predictable pieces get committed with confidence. The genuinely uncertain piece gets its own short, time-boxed phase where we prove feasibility on the client's real data first. That early phase answers the scary question cheaply, before a big number depends on the answer. Most clients respect this once I explain it, because it guards their budget as much as my team's sleep.

Put 'good enough' in writing, in plain language

The worst fixed-price fights are about the word 'working'. The client thinks working means ninety-nine percent right. The proposal quietly assumed eighty. Nobody wrote it down, so both sides are correct and both sides are upset.

I settle that at the start. We agree, in writing and in plain words, on what good enough looks like and how we will measure it together. A number, a test set, a review method. Dull to negotiate, priceless to have when someone later says, 'this is not what I paid for.' A written standard turns a shouting match into a five-minute check.

Scoping this way is slower up front, and I have lost a little sleep worrying it makes us look cautious next to a competitor who says yes to everything. But the projects hold. That discipline is a big part of how I keep the delivery promise I make at Shanti Infosoft, and you can see how we frame that work at https://shantiinfosoft.com.

A fixed price is a promise. I would rather make a smaller, honest one I can keep than a generous one that becomes a mess for both of us four months in.

It helps to understand how buyers actually shop for AI work in 2026 before you put a number on it.

When you scope a fixed-price project, where do you build in room for the things you cannot know yet?

Top comments (0)