July 13, 2026
A messy discovery call is where good projects start going sideways. I run every first call with the same loose structure now.
Start with the business, not the feature list. “What does success look like in six months” gets a more useful answer than “what pages do you need.” Features fall out of the goal, not the other way around.
Ask who says no. Every project has a budget owner and sometimes a separate approver. Knowing that upfront avoids a finished proposal getting vetoed by someone who was never in the room.
Get specific about the timeline driver. “ASAP” usually hides a real reason, a trade show, a funding round, a busy season. Understanding the actual deadline changes how I’d sequence the work.
End with next steps in writing. A short follow-up email restating what was discussed and what happens next keeps everyone aligned before a single line of a proposal gets written.
What have you already tried? Most businesses reaching out for a website or app aren’t starting from zero. Knowing what existing tools, spreadsheets, or half-built solutions are already in place avoids proposing something that duplicates effort or ignores a constraint I didn’t know existed.
What does the current process cost you? Getting a client to put a number, even a rough one, on the time or money a manual process currently costs reframes the whole conversation. A project that sounded expensive in isolation often looks cheap next to the cost of the problem it solves.
Who else has tried to solve this and failed? A past failed project, an agency that didn’t deliver, a previous developer who disappeared, tells me more about what to watch for than almost any other question. It also tells me what trust I need to rebuild before technical details even matter.
What would make this call a waste of your time? Asking this directly, early, surfaces deal-breakers, budget range, timeline, decision process, before either side invests more time than necessary in a mismatched project.
A structured discovery call is really a scoping tool disguised as a conversation. For how that scoping translates into a number, see How to Price a Freelance Web Design Project, and the SCORE business planning resources are useful if a client is still fuzzy on their own goals going into the call.
One discovery call started with a client describing a fairly small feature request, a way to email a quote to customers automatically. Twenty minutes in, following the “what does the current process cost you” question, it turned out that manually preparing and sending those quotes was consuming roughly ten hours of a staff member’s week, every week. The real project wasn’t a small feature, it was a quoting workflow that would save the business the equivalent of a quarter of a full-time role. The proposal, and the price, looked completely different once that was on the table, and the client agreed immediately because the value was suddenly obvious to both of us.
If I’d taken the original request at face value and quoted a small feature, I’d have undersold both the project and the value delivered. The surface-level ask is rarely the full picture, and a structured discovery call is what surfaces the difference between the two.
I now treat every discovery call as an investigation, not an order-taking session. The client knows their business better than I do, but they don’t always know which details are relevant to a developer, so it’s my job to ask the questions that surface them.
Not every client walks in with clear answers, and that is not a red flag on its own, it is often exactly why they need help in the first place. When a client struggles to articulate what success looks like, I have found it more useful to ask about a recent frustration instead: describe the last time this problem genuinely annoyed you. A specific, recent frustration is usually easier to access than an abstract goal, and it reliably reveals the same underlying priorities a cleaner “what does success look like” answer would have, just approached from a different angle.
I also keep a standing list of questions I almost always ask, even when they feel repetitive by the tenth call of the month. What happens if we do nothing and this problem stays unsolved for another year. Who on your team will actually use this daily, and who just approves it. What has surprised you most about a past project that did not go well. These are not clever questions, they are just reliably useful ones, and running through the same core list every time protects against the natural tendency to skip a question because a call feels like it is going well.
A discovery call that ends with a client feeling genuinely understood, not just heard, is doing more for the eventual project than any amount of impressive technical talk during the same conversation would.
The best discovery calls end with the client talking more than I did. If I am doing most of the talking on a first call, that is usually a sign I skipped ahead to pitching a solution before fully understanding the problem I was being asked to solve.
A discovery call done well makes the rest of the project feel almost inevitable, because both sides already agree on what they are actually trying to achieve together.
Discovery calls get easier with repetition, not because the questions change, but because the instinct for which follow-up question matters most in the moment sharpens with every call. The structure above is a starting point, not a script to read verbatim, and it should flex to fit whoever is actually on the other end of the call.
That flexibility is exactly what turns a template into a genuinely useful tool.
And if a call ever ends without a clear next step agreed by both sides, that is worth treating as an unfinished call, not a successful one, regardless of how pleasant the conversation itself felt in the moment.