How I Structure Discovery Calls With New Clients

A discovery call isn't a sales pitch, and it shouldn't feel like one. It's the first fifteen to thirty minutes of the actual engineering process — the point where a vague idea either turns into a scope that can be estimated accurately, or reveals that it isn't ready to be scoped yet. Most of what determines whether a project later goes smoothly or turns into a slow-motion scope-creep disaster gets decided in this conversation, long before a proposal is written or a contract is signed.

Over years of client work, I've settled on a fairly consistent structure for these calls. It's not a script — every project is different — but it reliably surfaces the information that actually matters, and just as importantly, it surfaces when a project isn't ready to be scoped at all.

The Structure I Use

1. What's Broken Today, Specifically

I start here deliberately, before talking about solutions. "We need a system" or "we need an app" tells me almost nothing — it's a solution shape, not a problem description, and jumping to solutions too early is how projects end up building the wrong thing well. I push for specifics: what exactly happens today that's a problem? Who hits that problem, and how often? What do they currently do instead — a spreadsheet, a manual process, three different tools stitched together with copy-paste?

The answer here isn't just informative — it's diagnostic. A client who can describe the problem precisely, with examples, is usually ready to scope a project. A client who can only describe it in generalities ("our process is inefficient") often needs a shorter, cheaper discovery engagement first, before a full build makes sense.

2. Who Touches This Workflow, and How Often

Every workflow has users, and every user has a different relationship to the problem. The person requesting the project (often a founder or operations lead) frequently isn't the person who'll use the resulting software daily. I ask who actually touches this process, how many times a day or week, and whether those people have been part of this conversation at all. A project scoped entirely from the perspective of the person paying for it, without input from the people actually doing the work, tends to miss requirements that only show up once real users start using the thing — which is the most expensive time to discover them.

3. What's the Cost of Doing Nothing for Another Six Months

This question does two things at once. First, it forces honest prioritization — if the cost of inaction is low, the project probably doesn't need to be rushed, and rushing it usually produces worse decisions. Second, and more usefully, it surfaces the real business case in numbers: hours lost per week, revenue left on the table, errors that cost money to fix, a competitor pulling ahead. Those numbers become the yardstick for scoping decisions later — when a feature request comes up mid-project, "does this address the thing that's costing us six figures a year" is a much better filter than "does this seem like a good idea."

If a client can't answer this question with any specificity, that's useful information too. It usually means the project is driven by a feeling rather than a measured problem, which isn't disqualifying, but it does mean the scope needs to stay smaller and more exploratory until the real cost becomes clearer.

4. What Does "Done" Look Like to the Person Paying the Invoice

I ask this explicitly, in those words, because the honest answer sometimes surprises both of us. Sometimes "done" is a specific, narrow outcome — "I just need our team to stop manually re-entering order data." Sometimes it's much bigger and vaguer than the budget being discussed can actually support, and that's far better to discover on a quick call than three weeks into a signed engagement. Getting this answer explicit, early, and in writing is the single best protection against scope disagreements later, because it gives both sides a shared reference point to return to when new ideas inevitably come up mid-project.

What Happens When the Answers Aren't Clear

If I can't get clear, specific answers to these four questions on the first call, I don't move to scoping or a proposal — I schedule a second call, sometimes after asking the client to talk to a few of the actual workflow users in between. This isn't a sales tactic to extend the relationship; it's a straightforward acknowledgment that a project built on a vague problem statement tends to go badly regardless of how skilled the engineering team is. A second call that produces real clarity is far cheaper than a signed project that has to be re-scoped in week three.

Why This Structure Works

The underlying logic is simple: a proposal is only as good as the information it's built on. A structure that forces specificity — on the problem, the users, the cost of inaction, and the definition of success — produces proposals that are accurate, which means fewer surprises, fewer disputes about scope, and a much higher chance the finished project actually solves the problem it was meant to solve. It also filters out projects that aren't ready to be built yet, which protects both the client's budget and the quality of the eventual engagement.

This is really the same discipline covered in more depth in why most custom software projects fail before they start — discovery is where a project's outcome actually gets decided.

Frequently Asked Questions

How long should a discovery call take?

Fifteen to thirty minutes is usually enough for a first call. The goal isn't to fully scope the project in one sitting — it's to determine whether the problem is specific and well-understood enough to move forward, or whether more groundwork is needed first.

What if the client doesn't know the cost of doing nothing?

That's a normal and useful answer. It usually means the project should start smaller — a short discovery or audit engagement to quantify the problem — rather than jumping straight to a full build based on a guess.

Should discovery calls be free?

I treat the first call as a free, no-obligation conversation. Its purpose is mutual — for the client to describe the problem, and for me to assess whether I'm the right fit and whether the project is ready to be scoped. Charging for this step tends to discourage the honesty that makes it useful.

Scoping a New Project?

If you're sitting on a project idea and want a discovery conversation that actually surfaces what the build needs before anyone writes a proposal, I'd be glad to walk through it with you. Explore my Custom Software Development and Technical Consulting & Architecture services, or see the full list on my services page.

Book a free 30-minute technical consultation →