Why the Discovery Call for AI Projects Is Different
A discovery call for AI projects is the structured conversation you have with a prospective client before you write a single line of scope or say a number out loud. It is different from a standard freelance scoping call because AI projects have a specific failure mode: the client knows what they want the tool to do but not what outcome they actually need, and if you quote on the first description, you'll build the wrong thing at the wrong price. The call exists to close that gap before it costs either of you.
I never quote on the first message. Not because I don't have a rough number in my head - I usually do - but because that rough number is based on what they said, and what they said in the first message is almost never the full picture. The call gives me the full picture. After it, I can price on the real outcome and scope on the real problem, and both of those numbers are usually different from what I would have said on first contact.
The Outcome-First Call Framework
I call my approach the Outcome-First Call. The premise is simple: most clients come in describing a feature. My job in the first fifteen minutes is to get them off the feature and onto the outcome - the actual change in their business or process when the thing works. Once I have the outcome, I can price on the value of that change rather than on the hours it takes me to build the feature. Those two prices are often very different, and the outcome-based one is almost always higher.
The call runs in three phases. First, the problem - I want to understand what's broken and what it's costing them today. Second, the outcome - I want to understand what specifically changes when it's fixed. Third, the reality check - I want to confirm who decides, what they've got to spend, and when they actually need it. Run those three phases in order and you'll have everything you need to write a proposal that wins.
Phase One: The Cost of the Problem Today
The questions I lead with are all about the current state of the problem - not what they want built, but what's broken right now and what that costs them. This is where you find out whether the project is worth doing at all.
- 'Walk me through what you're doing right now to handle this.' - Gets them describing the manual process, the workaround, or the gap. The answer tells me complexity and gives me a baseline.
- 'How much time does that take per week, and who's doing it?' - Time is a proxy for cost. If three people spend two hours each on something weekly, I now have a rough floor for how much the problem is worth solving.
- 'What happens when it goes wrong or falls through the cracks?' - This surfaces the real pain. The cost of failure is often a more powerful pricing anchor than the cost of time.
- 'Why hasn't this been solved already?' - Their answer tells me about constraints I'll run into: technical, organizational, or budgetary. It also tells me whether they've tried and failed, which changes my risk read on the project.
Phase Two: What Changes When It's Fixed
This is the most important phase and the one most people skip. Clients will tell you what they want the tool to do. They will not, unless you ask, tell you what they need to be true in their business when the tool is working. Those are different things, and the second one is what you price on.
- 'If this is working perfectly in three months, what does that look like for you?' - Forces them to describe the outcome, not the feature. The answer is your pricing target.
- 'What does success look like for the person using this every day?' - Shifts from what the tool does to what the user experiences. Often reveals requirements the initial spec missed.
- 'Is there a decision, a process, or a result that this needs to feed into?' - Surfaces downstream dependencies you need to scope for. An AI output that feeds a human review step is a different build than one that feeds an automated action.
- 'What would make this a clear win for your team six months from now?' - Gets you their definition of value. Reference this directly in your proposal.
Phase Three: The Reality Check
The most polished discovery call fails if you skip this phase. Decision-maker, budget, and timeline are the three filters that tell you whether this conversation leads to a real project or a proposal that disappears into a committee. Ask all three before the call ends.
The three reality-check questions and what each answer tells you
| Question | What You're Actually Checking |
|---|---|
| 'Who else needs to sign off on this?' | Whether you're talking to the decision-maker or an intermediary. If there's a committee, your proposal needs to survive a room you won't be in. |
| 'Do you have a budget range in mind for this?' | Whether the project is financially viable before you spend time scoping it. A vague answer is information - it usually means the budget is soft or undefined. |
| 'What's driving the timeline on your end?' | Whether there's a real deadline or a wishful one. Real deadlines have a reason attached. 'As soon as possible' with no reason is usually not urgent. |
How to Spot a Bad-Fit Client Before You Quote
Discovery calls also exist to disqualify. Not every project is worth taking and not every client is worth serving - and the call is the cheapest place to find that out. I pass on a project when I see a combination of these signals:
- They can't describe the outcome, only the feature - and push back when I try to redirect to the outcome. If they don't know what success looks like, you'll be building to a moving target.
- The problem's cost is low and the scope is high. If fixing it saves a small amount of time on a low-stakes process, the math on a meaningful engagement won't work for either side.
- They've already built this twice and it failed both times for reasons that weren't technical. Organizational blockers don't get fixed by a better tool.
- They want a rate per hour before they want a scope. Hour-rate conversations anchor you in the wrong place from the start and set up the relationship for friction.
Moving from the Call to a Scoped Proposal
At the end of the call, I do one thing before we hang up: I read back what I heard in two or three sentences. The problem, the outcome, and the constraint. I ask them to confirm it's right. That confirmation is the foundation of the proposal. Everything I write after that maps back to those three things.
The proposal itself is short. One page, three sections: the problem as I understand it, the outcome we're building toward, and the scope - what I'll deliver, what's out of scope, and the investment. I price on the outcome, not on hours. If the outcome is worth a meaningful amount to their business, I price there and justify it by referencing the cost of the problem they described on the call. That's the Outcome-First Call working as designed - the discovery conversation becomes the pricing rationale.
Put the Outcome-First Call to Work
The Outcome-First Call is a skill, not a script. The questions above are starting points - you'll adapt them to each client and each project type. What stays constant is the sequence: cost of the problem first, outcome second, reality check third. Run that sequence consistently and you'll write better proposals, win at better prices, and take on fewer projects that drift.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What is a discovery call for AI projects?
A discovery call for AI projects is a structured thirty-minute conversation you run with a prospective client before you quote or write a proposal. Its purpose is to uncover the real outcome they need, the cost of the problem as it stands today, and whether they have the decision-making authority and budget to move forward. It's the difference between quoting on a vague description and pricing on a fully understood brief.
Why shouldn't I just quote from the first message?
Because the first message almost always describes a feature, not an outcome. When you quote on a feature description, you're pricing on incomplete information - you don't yet know the cost of the problem, the downstream dependencies, or what success actually looks like for the client. Discovery gives you those inputs and almost always changes the scope and the price you'd have named without it.
How long should a discovery call for an AI project take?
Thirty minutes is the target. That's enough time to cover the cost of the problem, the outcome they need, and the decision-maker and budget reality check - all three phases of the Outcome-First Call. If you're going past forty-five minutes on discovery, you're likely going too deep into solution mode before you've confirmed the project is real and viable.
What do I say when a client asks for a price before any call?
The response that works consistently: 'I want to give you a real number, not a guess. Can we spend thirty minutes so I understand what you actually need? Then I can quote something I'll stand behind.' Frame the call as serving their interest - getting an accurate quote rather than a rough estimate that will need to be revised later. Most clients respond well to that framing.
How do I handle a client who can't describe the outcome?
Treat it as an opportunity, not a disqualifier. If a client can describe the problem clearly but can't yet describe what success looks like, helping them define the outcome is a legitimate and valuable service. Scope a short definition phase before the build phase - you get paid to think before you build, and they get a much better brief going into the main project.
What are the red flags that should make me pass on a project?
The clearest signals: they can't describe the outcome and resist the question, the problem's cost is too low to support a meaningful engagement, the project has failed twice before for non-technical reasons, or they anchor immediately on an hourly rate rather than a project outcome. Any one of these warrants caution. A combination of two or more is usually a pass.
Last reviewed by Duncan Rogoff on July 25, 2026
