I end most discovery calls in under 30 minutes, and clients almost always thank me for it. Not because I am not interested in their business — but because the job of a discovery call is clarity, not a performance. By the half-hour mark I usually know whether we can help, what the first use case should be, and whether it is worth either of our time to go further. Dragging that out to fill an hour would only add slides, not value.
Here is what I am actually doing in those 30 minutes, why I am happy to end early in either direction, and why a consultancy that needs ninety minutes and a deck to tell you "it depends" is usually a warning sign.
What a discovery call is actually for
A discovery call is not a pitch and it is not a demo. It is a qualification conversation — for both sides. You are working out whether we are the right team; I am working out whether there is a real, solvable problem with data behind it and an owner ready to act. If I spend the call talking instead of listening, I have failed at the one thing the call exists to do.
So I ask a lot, and I interrupt politely. I would rather reach an honest "here is the situation" in 25 minutes than a vague "let us schedule a follow-up to explore synergies" in sixty.
The four things I am trying to learn — fast
Almost every useful discovery call answers four questions. Get them clear and the path is obvious; leave them fuzzy and no amount of meeting time helps.
1. What is the real problem — and the number behind it?
Not "we want to use AI" but "support takes too long and it is costing us renewals," with a metric attached. If you can name the outcome and the number that would prove it moved, we can design backwards from there. If you cannot yet, that is fine — finding it is the first piece of work.
2. Is the data actually there?
Most AI ideas live or die on data, so I ask bluntly: does the data this needs exist, is it accessible, and is it clean enough to trust? If it is scattered across five systems, that is a data engineering step to sequence first, not a detail to wave away. Knowing this in the first call saves months later.
3. Is there a viable first use case?
I am listening for the smallest piece of work that is valuable enough to matter and small enough to ship. The best first project is rarely the most ambitious one — it is the one that proves value quickly and builds the foundation the ambitious one will need.
4. Are you ready to act on it?
Is there a budget, an owner, and an appetite to run the thing after launch? AI is not a project you finish; it is something you operate. If the readiness is not there yet, I would rather say so than sell you a proof of concept that stalls.
Why I will happily end the call early — both ways
If the answers line up, I do not need more time to be polite. We have a clear first use case, so the honest next step is to scope it — and at Crux Digits that usually means a working prototype by the second call, not another workshop. Ending early there is a good sign: it means the problem is clear enough to build.
And if the answers do not line up, I will tell you that too, in the same half hour. Sometimes the most valuable thing I can say is "do not build that yet — fix the data first" or "an off-the-shelf tool will do this for a fraction of the cost." I am vendor-neutral by design, so a short call that saves you a wasted budget is a win, not a lost sale. You can review our transparent pricing any time, but I would rather you spend it on the right thing.
Why long presentations are a red flag
There is a reason "slideware" is a dirty word among the technical buyers we work with. A long, polished discovery presentation often signals a consultancy selling certainty it has not earned — decks instead of working software, billed hours instead of shipped value. Real engineering is humble in the first meeting because the honest answer to most AI questions is "let us prove it with a small build," not "here are forty slides on our methodology."
The teams that ship AI tend to talk less and build sooner. We would rather show you a rough prototype on the second call than impress you with a roadmap on the first. If you want to see what that looks like in practice, our case studies are the short version.
But what if 30 minutes is not enough?
Sometimes it genuinely is not — a big organisation, several stakeholders, a problem that touches three departments. When that happens, the call's job simply changes. It is no longer to decide; it is to work out exactly who else needs to be in the room and what they should bring. A short first call that ends with "here is precisely who we need next and which data to pull" is far more useful than a long one that ends with a vague promise to reconnect. Specificity is the deliverable, whatever the timebox.
There is a second reason I keep it tight: the 30 minutes is a filter that protects you as much as me. If we cannot reach clarity quickly when you have brought the right inputs, that tells you something real about how the whole engagement would feel. A partner who cannot be concise in the first conversation rarely becomes concise once the invoices start. Treat the length of your discovery calls as a small, honest preview of the working relationship — because that is exactly what it is.
How to get the most from your next discovery call
If you are about to brief any AI partner, you can make the call short and useful by bringing three things: the problem stated as an outcome with a number, an honest read on where the relevant data lives, and the name of whoever will own the result. With those, a good engineer can tell you something real in half an hour. Without them, even a long meeting just postpones the same questions.
That is the whole philosophy: respect the problem, respect your time, and earn the next step by being clear rather than by being lengthy.
The honest close
A 30-minute discovery call is not me rushing you — it is me proving that I understood the problem fast enough to be useful. If it is a fit, we scope a small build and you see something real quickly. If it is not, you leave with a clear reason and no wasted spend. Either way you get clarity, which is the only thing a first call should ever sell. Book a free consultation and let us map your first use case together — I will try to give you back twenty minutes.
Frequently asked questions
How long should a discovery call be?
Long enough to get clarity and no longer. For a focused AI problem, 30 minutes is usually enough to establish the real outcome, whether the data exists, a viable first use case, and whether you are ready to act. Bigger, multi-stakeholder problems may need more time, but the goal is still clarity, not length.
What should I prepare for an AI discovery call?
Bring three things: the problem stated as an outcome with a number, an honest read on where the relevant data lives and how clean it is, and the name of whoever will own the result after launch. With those, a good engineer can give you a real answer in half an hour.
Is a short discovery call a sign of low interest?
No — usually the opposite. A short call means the problem was clear enough to qualify quickly, so we can move to scoping a small build. It can also mean an honest no-go, which saves you a wasted budget. Either way you leave with clarity rather than a vague follow-up.
Why are long sales presentations a red flag for AI projects?
Because the honest answer to most AI questions is to prove it with a small build, not to present forty slides of methodology. Long, polished decks often signal billed hours and certainty that has not been earned. Teams that actually ship AI tend to talk less and build sooner.