What a good discovery call actually looks like
The first conversation decides whether a project succeeds. Here is what we ask, and why we sometimes tell people not to build.
A discovery call is not a sales call. Its job is to find out whether there is a real problem worth solving, and whether software is the right tool for it.
The questions that matter
We spend most of the call on the problem rather than the proposed solution.
- What does this cost you today, in hours or in money?
- Who exactly experiences the pain, and how often?
- What have you already tried, and why did it stop working?
- What happens if you do nothing for another year?
- How will you know, six months after launch, that this worked?
That last question is the most revealing. If nobody can name a number that should move, the project has no definition of success — and a project without one cannot be finished, only abandoned.
Scope is a conversation about trade-offs
Every project has three levers: scope, timeline, and budget. You may fix two. Pretending otherwise is how projects end up late, over budget, and disappointing simultaneously.
We would rather have an uncomfortable conversation in week zero than an unpleasant surprise in month four.
Sometimes the answer is don't build
Occasionally the honest recommendation is that an off-the-shelf tool already solves this, or that the underlying issue is a process problem that software will only automate and entrench.
Saying so costs us a project and earns something more useful. Clients who trust that we will tell them when not to build tend to believe us when we say something is worth building.
What you should leave with
By the end of a good discovery call you should have a clear sense of the shape of the work, the rough range of effort, the main risks, and what happens next — whether or not you choose to work with us.
If you leave with only a proposal and a price, that was a sales call.
