Discovery Call Questions I Ask Every Web Client Before Quoting

My worst quote ever was for a "simple brochure site." I priced it in ten minutes after a friendly twenty-minute call, and the client was lovely. Three weeks in, I learned that "brochure" included a members area, an Arabic and English version, and an import of 900 products from a spreadsheet nobody had opened since 2019. I did the work. I also earned roughly the hourly rate of a part-time barista.

Nothing was wrong with the client. The call was wrong. I asked what they wanted and wrote down the answer, which is a different thing from finding out what they needed. Since then I've kept a short list of discovery call questions, and I skip none of them, even when a lead is charming and in a hurry. Especially then.

This post is that list, with the reason behind each question and the answer that makes me slow down. It's built for freelance web projects, but most of it works for any small agency job.

Ask about the problem before the website

"What do you want built?" gets you a feature list. The feature list is usually a guess at a solution to a problem you haven't heard yet. So I open with a different question: what happened that made you decide to do this now?

Something always happened. A competitor launched a new site, a developer left, the old site got hacked, a campaign needs a landing page by March. The trigger tells you the real deadline and the real stakes, and it tells you who is nervous. A site rebuild triggered by "our agent quit and the site is down" is a very different job from one triggered by "we feel dated."

Rob Fitzpatrick's The Mom Test is a book about customer interviews for startups, but its core idea transfers cleanly: ask about specific past events instead of hypothetical futures. Nobody can reliably tell you whether they'd use a feature. They can tell you what they did last Tuesday when the old system failed. I now ask "walk me through the last time a customer tried to book something on your current site" and I take notes like a court reporter.

Two follow-ups I always add. What does success look like in six months, in numbers if possible? And what would make you call this project a failure? The second one is the better question. People answer it fast, and the answers are specific.

Find out who decides and who pays

I've been burned by the sponsor who loves my proposal and then needs "sign-off from the partners." So early in the call I ask who else will have an opinion about this project, and who signs the invoice.

If the answer is a committee, I ask to meet the loudest member, or at least to get their written requirements before I quote. A decision-maker I never meet is a stakeholder who will appear at the end with a list of changes. That connects directly to scope, which I covered in how I handle scope creep. Most scope creep I've dealt with was an undiscovered stakeholder in disguise.

The budget question makes freelancers squirm, so here's the phrasing I use: "Projects like this usually land somewhere between X and Y depending on the answers to what we're discussing. Does that range sit in the same world as what you had in mind?" It's not a trick. It saves us both a week of proposal writing if the number is a different order of magnitude from their expectation. The answer I dislike most is "we don't have a budget in mind." That usually means they've never bought this before, and I need to spend more of the call explaining what good work costs. I wrote about how I arrive at those ranges in how I actually price freelance web development work.

Ask what already exists

This is the section where my brochure-site quote fell apart. Before any quoting, I want an inventory of what is already out there, and I ask it as plainly as that.

What is the current site built on? Who has the hosting login and the domain registrar login? Is there content to migrate, and how much of it is real versus abandoned? Are there integrations: payments, a CRM, a booking tool, a newsletter list? Is there analytics, and does anyone read it?

Migration deserves its own paragraph because it is where hours vanish. If the URLs are changing, someone has to map old addresses to new ones and set up redirects, or the client's search traffic quietly dies. Google's guide to site moves with URL changes is the document I send people who think a redesign is only a visual job. I ask for a crawl or a sitemap export on the call, and I get a rough page count before I say a price out loud. "About 40 pages" and "about 900 URLs" are not the same project, and clients are often honestly unaware of which one they have.

Domain access is the unglamorous question that has stalled more launches than any technical problem. If the registrar account belongs to a former employee's personal email, I want to know in week one, not launch day.

Constraints nobody mentions unless you ask

Some requirements are invisible until they're violated. I ask about them directly, because the client assumes they're obvious.

Languages and right-to-left layouts, for one. Accessibility, for another: if the client is a government body, a school or a larger company, there may be a legal or contractual standard, and the W3C Web Accessibility Initiative's planning guidance is a good reference for the conversation. Retrofitting accessibility at the end costs far more than designing for it from the start, so I'd rather know now.

Then there's who maintains the site after launch. If the answer is "the marketing intern, in WordPress," that shapes my technology choices more than anything else on this list. I once proposed a lovely headless setup to a client whose only technical person was an office manager. It was the wrong tool for them and I knew it halfway through the call, but I had already started getting excited. Now I ask the maintenance question early enough that it can veto my enthusiasm.

Other quick ones: any hard launch date and what it's tied to, any brand guidelines or a designer already involved, any legal copy (privacy policy, cookie consent) they need, and whether they have photos or I should budget for stock. Each takes thirty seconds to ask and has cost me a day when I didn't.

Close the call with a promise you can keep

At the end I repeat back what I heard in about five sentences, and I say when they'll get a written proposal. Then I do exactly that. The recap catches misunderstandings while they're cheap to fix, and clients often correct one detail in a way that changes the quote.

I also tell them what I will need from them: a named decision-maker, access to current accounts, and any existing content. Setting that expectation before the contract keeps "waiting on the client" from becoming my fault in a timeline conversation later. When the call went well, the proposal nearly writes itself, and I've shared the structure I use in my web development proposal template.

Not every lead should get a proposal, and discovery is also where I find that out. A client who refuses to say who decides, won't discuss budget and wants a fixed price by Friday is giving me information. Sometimes the best output of a discovery call is a polite no.

Try it on your next call

You don't need the whole list. Pick the three questions you've been skipping because they feel awkward, probably the budget one and the "who else decides" one, and write them at the top of your call notes before your next lead. Ask them in the first fifteen minutes, when it feels slightly rude, instead of the last five, when it feels like an interrogation.

After the call, compare what you learned with what you would have quoted from a form submission. If the gap is large, you've found your own version of my brochure site. This is the filter I use for the projects that come through my freelance practice, and it has saved me from more bad fits than any contract clause.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.