How We Structure a Discovery Call Before Starting a Project

The Call That Determines Whether the Rest of the Project Goes Smoothly

Most of the problems that derail a website project — scope creep, mismatched expectations, timelines that blow past their estimate — trace back to questions that weren't asked, or answers that weren't gotten specific enough, before the work started. A discovery call isn't a sales formality we rush through to get to a proposal. It's where we gather the information that actually shapes the plan.

Starting With the Business, Not the Website

We don't open with "what pages do you want?" We open with questions about the business itself: what it does, who its customers are, how those customers currently find and choose the business, and what's working or not working about that today. A website is a tool serving a business goal, not an end in itself, and we can't scope the tool well without understanding the goal it's meant to serve.

Getting Specific About the Actual Problem

"Our website looks outdated" is a starting observation, not a complete brief. We push further: is the concern really about appearance, or is it that the site isn't generating enough leads, isn't ranking well, is hard to update, or doesn't work properly on mobile? Different underlying problems call for different solutions, even when they're described with similar language at the outset. Getting this right early avoids designing a beautiful solution to the wrong problem.

Mapping Out Who's Involved

We ask directly who will be reviewing designs, who has final sign-off, and who else might weigh in along the way. This isn't about bureaucracy for its own sake — projects with unclear decision-making are one of the most common sources of stalled timelines, because feedback arrives in scattered, sometimes contradictory rounds instead of a single consolidated review. Knowing the decision-making structure upfront lets us plan the review process around it rather than discovering the complexity mid-project.

Understanding the Current Technical Situation

If a website already exists, we ask about the current platform, hosting situation, domain registrar, any existing integrations (CRM, booking tools, payment processors), and what content is worth preserving versus rebuilding. This avoids surprises later — discovering, for instance, that a domain is locked with a registrar nobody has login access to, or that an existing CRM integration needs to be replicated exactly for the business to keep functioning normally after launch.

Talking Through Content Readiness

Does the client have existing copy, photography, and service descriptions ready to use, or does content need to be created as part of the project? This affects both timeline and scope significantly, and it's much better established upfront than discovered when a page is sitting half-built waiting on copy that was assumed to already exist. We're direct about this because content gaps are one of the most common causes of a project stalling in the build phase.

Setting Realistic Expectations on Timeline and Budget

We talk through a realistic timeline range based on what's being described, and we're upfront if a stated budget and a described scope don't match. Better to have that conversation in the first call than after a proposal has already been sent and expectations have started to calcify around a number that isn't achievable for what's being asked. We go into more detail on how a quote is actually built in how we price web development projects, and how a realistic schedule breaks down in what a website project timeline actually looks like.

Identifying Integration and Automation Needs Early

Many projects need the site to connect to something beyond itself — a CRM, a booking system, an email platform, a chat or voice tool for handling inbound leads. We ask about this directly rather than waiting for it to surface later, because integrations affect both cost and technical planning from the start. This is often where the conversation naturally extends into the automation side of what we do, covered in more detail in our AI automation stack, explained.

What Comes Out of the Call

By the end of a discovery conversation, we should have enough to put together a real scoped proposal — not a generic package, but a plan built around the specific business, problem, timeline, and budget discussed. If something doesn't add up — the budget doesn't match the scope, the timeline isn't realistic, or the project isn't actually a good fit for what we do — we say so directly rather than sending a proposal that papers over the mismatch. More on how we think about that fit question in what we look for before taking on a new web project.

Why This Takes Longer Than a Quick Chat

A thorough discovery call usually runs longer than either side expects going in, and that's intentional. The time spent here is far cheaper than the time lost later untangling a misunderstanding that surfaces three weeks into a build. It's the least expensive place in the entire project to get things right.