How do you scope and estimate an AI project for a client when nobody has done it before?

The client wants a number. You want to give them one. And the truth sitting between you on the table is that nobody in the room, on either side, has ever done this exact thing before.

That’s where every small agency lands the first time a client asks for a real AI project. Not a chat about AI. A scope, a date, and an estimate. The instincts you’ve built over forty website builds don’t transfer, because there’s no forty-first of this. So how do you scope and estimate work with no track record, without lowballing yourself into a rough quarter or scaring the client off with a number buried under caveats?

The answer in one line: scope it in phases and estimate it with a range, because a single number for work nobody’s done before is a guess wearing a tie. Start with a short discovery phase that has its own Deliverables and its own effort estimate. Use it to find out what their data looks like, who on their side can make decisions, and whether the thing you’re proposing is even the right first thing. Then estimate the build from what discovery taught you, not from what the sales call hoped. Put every unknown on the page where the client can see it, give a range instead of a point, and agree on a checkpoint where you both look at plan versus actual and decide what happens next. Experienced shops estimate every unfamiliar Job this way. AI work just happens to be the most unfamiliar thing most of us have quoted in a decade.

Why AI projects break normal estimating

Your estimating instinct comes from repetition. You’ve built forty websites, so the forty-first has a shape in your head before the client finishes the sentence. AI projects don’t have that yet. The tools change monthly. The client’s data is always messier than described. The “simple automation” turns out to depend on a system nobody has touched since 2019 and nobody wants to be the one to touch now.

Three things go wrong. The setup effort is invisible until you’re in it: access, cleanup, permissions, the two weeks waiting for someone in IT to answer an email. Quality is a judgment call, and the client’s idea of “good enough” moves the moment they see the first output. And the scope wants to grow. Every demo produces a “could it also” from someone in the room, and because the technology feels like magic, nobody thinks to ask what “also” costs in effort.

Estimate this like a website and you’ll be wrong in the same direction every time. Low.

Scope it as phases, not a project

Break it into at least two Jobs, or one Job with phases the client signs off on separately.

Phase one is discovery. Its Deliverables are concrete: an inventory of the data and systems involved, a short list of what could be automated or assisted and what shouldn’t be, a recommendation for one first use case, and an estimate for phase two you’d stand behind. It’s small, it has a hard end date, and it produces something the client can use even if they never hire you for the rest.

Phase two is the first build. One use case. Setup, a pilot alongside the current way of working, a measurement period, and a decision meeting. Not the whole roadmap. One thing, done properly, with a beginning and an end.

Phase three, if it exists, gets estimated after phase two ships. Anyone who wants a firm number on phase three today is asking you to make something up, and you should decline, kindly, the way you’d decline to guess their weight.

This is the same logic as charging for discovery on any Job. The difference with AI work is that skipping discovery isn’t a slightly worse estimate. It’s a coin flip with your margin on the table.

Put the unknowns on the page

Most proposals hide uncertainty because it looks unprofessional. With AI work, hiding it is the unprofessional move, because the client will meet the unknowns anyway, in week three, at your expense.

Write them down as their own section: “Things we don’t know yet, and how each one changes the estimate.” Access to your systems: if it takes two days, fine; if it takes two weeks, phase one slips. Data quality: if the records are consistent, the build lands at the low end; if they need cleanup first, that’s a Deliverable we haven’t planned. Approval: if one person can sign off on outputs, we move; if it’s a committee, add review rounds and possibly a snack budget.

Then estimate each Deliverable as a range, low and high, and say what pushes it toward each end. A client who sees “12 to 20, depending on whether the export works” trusts you more than one who sees “16.” The first tells them you’ve thought about it. The second tells them you’ve guessed and rounded. We laid out the method in How do I price a project when I can’t predict the effort?, and it applies here without changes.

Write the brief so the scope can’t grow on its own

The biggest risk on a client AI project isn’t the technology. It’s the “could it also.” The demo works, someone senior gets excited, and by Friday the one use case has become four, none of them planned, all of them expected on the original date.

Your brief has to name the one use case in plain words and name what’s out. “Phase two automates the weekly summary report. It doesn’t touch customer-facing email, the CRM, or the intake form. Those are candidates for later phases and each gets its own estimate.” Say it at kickoff. Put it on the first page. When the “also” arrives, and it will arrive smiling, answer with a change order and its own effort.

The mechanics are the same as any scope-creep defense, and we covered them in How do I write a project brief that prevents scope creep?. With AI work the creep just moves faster and every step of it sounds more reasonable.

Phase one buys the accuracy of phase two

Clients need to hear this part, and it’s why the phased approach is more than self-protection. Discovery isn’t overhead. It’s where the estimate for the build comes from.

Before discovery, your phase two estimate is a range so wide it’s nearly useless. After a couple of weeks inside their systems, you can plan Deliverables with effort estimates you believe, you know who approves what, and you’ve probably killed one bad idea before it cost anyone anything. The client is paying a small amount of effort to turn a guess into a plan. Say it exactly that way.

Then hold yourself to it. Log effort in phase one against its Deliverables, compare it to what you estimated, and show the client the comparison at the checkpoint. If you were close, they’ll believe your phase two number. If you weren’t, you’ve learned something about estimating this kind of work, and you learned it on a small Job instead of a large one. Cheap tuition.

The Bottom Line

Nobody has done this exact project before, including you, so don’t price it like you have. Scope a small paid discovery phase with its own Deliverables. Put the unknowns on the page. Estimate the build as a range with a checkpoint, and name the one use case that’s in and the three that aren’t. Then track effort against the plan while it’s live, because on AI work drift shows up as extra review rounds and data surprises, and you want to see it the week it happens.

The shops that get hurt on client AI work aren’t the ones who estimated wrong. Everyone estimates unfamiliar work wrong. They’re the ones who found out at the end.

FAQ

What if the client insists on one fixed number for the whole thing?

Give them a fixed number for phase one and a range for phase two, and explain that the range narrows after discovery. If they still insist, they’re asking you to carry all the risk of unknowns neither of you can see. Price that risk into the high end, or decline politely.

How long should discovery be?

Long enough to answer the unknowns you listed and no longer. For most small-client AI projects that’s a couple of weeks of part-time effort. If it’s stretching, the client probably isn’t ready, and that’s a finding, not a failure.

Should we build in a “kill” decision?

Yes, at the end of phase one and again after the pilot. Deciding not to proceed is a legitimate outcome that saved the client a larger mistake. Frame it as a Deliverable.