A founder called me four months ago wanting to “do something with AI” for his sales team. Twenty minutes into the discovery call, I mentioned we’d “build an AI system that flags compliance gaps in real time,” and he stopped me. “We tried AI last year. It was a mess.” The call never recovered. We scheduled a follow-up that didn’t happen.
The problem was real. His team had a compliance issue we’d solved before, in very similar conditions. We’d built something nearly identical: a call compliance analyzer for an enterprise tech client that caught misselling flags at 40% better accuracy than their manual QA team.
The word “AI” killed the conversation before we got to scope.
That week, I stopped saying “AI” in the first fifteen minutes of every discovery call.
The Three Responses “AI” Triggers Early
I’ve run enough discovery calls to recognize the pattern now. When a founder hears “AI” in the first few minutes of a scoping conversation, one of three things happens, and none of them move us toward a useful proposal.
Magic thinking. The founder mentally inflates what they’re asking for. A request to summarize call recordings becomes “a system that tells me everything important about any conversation, in real time, in any language.” Not because they’re being unreasonable. Because “AI” is a marketing word right now, and marketing words carry the weight of every product demo they’ve seen in the last eighteen months.
Budget sticker shock. “AI projects are expensive.” They’ve read the case studies. They’ve talked to agencies. Before I’ve scoped anything, they’re already anchoring to a number they’re not sure they can justify. We’re then negotiating against a phantom proposal, and I’m spending the call defending a price I haven’t even quoted.
Defensive “we already tried that.” This one’s the hardest to recover from. They spent money on something, it didn’t work, and now “AI” is attached to that failure in their memory. What they tried might have been completely different from what we’d build. But we’re fighting that association for the rest of the call, and the founder is usually too polite to say so directly.
McKinsey’s 2023 State of AI survey found that AI adoption failures are often rooted in misaligned expectations, not technical limitations. That tracks with what I see on calls. The word “AI” does a lot of framing before the conversation starts, and most of that framing isn’t useful at the scoping stage.
What I Say Instead
I’m not avoiding the word to be coy. I’m avoiding it because I want to understand the actual workflow before I start proposing a solution.
Here’s what that looks like in practice.
Instead of: “We’d build an AI model to process your sales calls.”
I say: “It sounds like you want someone reviewing every call for specific signals, and you don’t currently have the headcount to do that. Is that right?”
That version surfaces the real problem. The founder responds. They add texture. “Not just signals. We need to know if the rep mentioned our refund policy on every call. That’s the compliance flag.” Now I know what I’m building before I’ve said anything about how.
Instead of: “An AI assistant for your support team.”
I say: “What happens when a support ticket comes in that the rep can’t answer from memory? Walk me through that.”
They describe the workflow. The workaround they use now. How long it takes. Who it blocks. By the time they’ve finished, I know whether this is a retrieval problem (we need a knowledge base the rep can query) or a generation problem (we need a draft response the rep can edit). Those are different builds with different cost structures.
Instead of: “We could automate this with AI.”
I say: “What does the manual version of this currently look like? How many people, how many hours a week?”
The manual version tells me whether automation is worth building. If it’s fifteen minutes a week for one person, they don’t need custom AI development services. If it’s three hours a day across a ten-person team, we’re having a real conversation. I’ve found that founders appreciate when you do this math with them, rather than for them.
Harvard Business Review has written about how jargon creates distance between specialists and the people they’re trying to help. In our category, “AI” has become that word. Not because it’s inaccurate, but because it carries too much meaning before the conversation has a chance to define it.
When “AI” Comes Back
I don’t avoid the word forever. I just wait until it’s useful.
Once I understand the workflow, the constraints, and what the founder actually wants to be different, I start naming the technical components. That’s when “AI” is worth saying, because I can be specific about it.
“We’d use a language model here, not a rule engine, because the output needs to be a readable explanation. Your compliance team has to act on it, not just read a flag.”
“The part that needs AI is the summarization step. The intake routing can be a decision tree. You don’t need a model for routing, and a rule engine is more auditable.”
“We’d use Deepgram for the transcription layer and a fine-tuned classifier for the rubric scoring. Both are technically AI, but they’re doing different jobs, and they’re priced differently.”
At this point in the call, the founder isn’t hearing “AI” as a category. They’re hearing specific technical choices with reasons. That’s a different conversation, and it’s one they can actually evaluate.
How This Changes the Proposals I Write
The first benefit isn’t better calls. It’s sharper proposals.
When I start with the problem, I scope the right thing. The proposals don’t run over because I’m not estimating a half-formed idea. I’m estimating a described workflow with known inputs and a defined output.
Three things changed measurably after I started running calls this way.
Fewer post-proposal revisions. When a founder reads a proposal and says “this isn’t quite what I meant,” it’s almost always because the scoping conversation was anchored around a technology, not a problem. Problem-first discovery closes that gap. Not committing to timelines on unfamiliar requirements works for the same reason: I need to understand the problem before I can estimate the work.
More honest “not yets.” Some founders describe a problem that’s genuinely not ready for a custom build. The data isn’t clean enough. The manual process hasn’t been defined clearly enough to automate. If I get there early in the call, I can say “I don’t think this is an AI problem yet. Here’s what would need to be true first.” That conversation doesn’t happen when we’re already deep into discussing the system.
Better match between complexity and price. When I scope from the workflow outward, I end up recommending the simpler solution more often. Sometimes a well-designed conditional form is the right answer, not a language model. Founders remember when you tell them they don’t need something. It builds more trust than pitching the bigger build.
A Note on Transparency
To be direct: I’m not hiding what we build. We build AI products. That’s the business, and our entire team is organized around it.
But the founders who become good clients aren’t the ones who came in saying “I need AI.” They’re the ones who came in saying “I have this problem” and discovered, through the conversation, that AI was the right tool.
The discovery call is my chance to be the person who helps them figure out which it is. Not someone selling a category, but a PM who actually understands what the work involves. If I lead with “AI,” I close that window before it opens.
The word comes back. It always does. Just not in the first fifteen minutes.
If you’re trying to figure out whether an AI build is actually the right solution for what you’re dealing with, book a 30-minute call. We’ll talk through the problem first, and I’ll tell you honestly whether AI is the right tool, and if it is, what kind.
FAQ
What does a discovery call with Kalvium Labs actually look like?
It’s 30 minutes. The first half is about the current manual process, not the solution. I want to understand what’s broken, how often, and who’s affected. The second half is me asking clarifying questions based on what I heard. We don’t send a proposal until we’ve had that conversation, because a proposal written against a vague AI brief is usually wrong in one expensive way or another.
How much do AI development services typically cost?
Small projects (a focused automation or prototype) run $5,000-$8,000 over two to four weeks. Medium builds (a full AI feature or integration) are $15,000-$25,000 over one to three months. Larger systems with multiple components run $30,000-$50,000 over three to six months. The scope I write after a problem-first discovery call tends to be more accurate than estimates written against a general “AI brief.”
Does it feel dishonest to avoid the word AI early in a call?
No, because the goal isn’t concealment. It’s sequencing. If I named the technology before I understood the problem, I’d be leading with a solution. That’s not honest scoping either, it’s just a different kind of misdirection. The word comes back as soon as I understand what we’d actually build. At that point it’s useful, not confusing.
What happens if you decide AI isn’t the right solution?
I’ll say that on the call. If the problem is better solved by a simpler automation, a process change, or something off-the-shelf, I say so. We’re not trying to sell AI for its own sake. If the problem does turn out to be a fit, I’ll explain exactly why, and what specifically we’d build, before anyone signs anything.
How long does it take to go from discovery to working prototype?
For well-defined problems with accessible data, we can have a working prototype in 72 hours. For builds where we need to assess data quality or integration constraints first, a realistic window is one to two weeks before you’re seeing something functional. Either way, you see the actual system before any further commitment. The discovery call is how we figure out which window applies.
