The five questions we ask before quoting any website project

The fastest way to give a client a wrong number is to answer their question before asking your own. "How much for a website" sounds like it deserves a quick reply, and plenty of agencies will give one on the spot, but that number is almost always a guess dressed up as a quote, built on assumptions that haven't been said out loud by either side.

We've settled on five questions we ask before any number goes on paper. None of them are exotic. What matters is that we actually wait for real answers before pricing anything, instead of treating them as formalities to get through on the way to a proposal.

Not "look professional," which every client says and which means something different to each of them, but the specific jobs the site needs to perform: generate leads through a form, sell products directly, explain a service complicated enough that most visitors won't understand it from the homepage alone. The answer changes almost everything about structure, and it's the question most likely to get a vague answer on a first call.

We push past the vague answer with a follow-up: what does a visitor do right before they become a customer, today, without a website at all. That question usually surfaces the real requirement, whether it's a phone call, a booking, or a specific document they need to see, and it's a much better foundation for a sitemap than "make it look modern."

A site that a solo founder will update themselves needs a genuinely different content system than one a dedicated marketing person will manage daily, and both are different again from a site nobody plans to touch after launch. We ask this early because it changes the platform decision, not just the training we provide at the end.

The honest answer here is often "we're not sure yet," which is fine, but it changes how we scope things. We'll default toward simpler, more forgiving tools when the future maintainer is unknown, because building something that requires a developer for every text change is a bad bet when nobody's confirmed who that developer will be.

"As soon as possible" isn't a timeline, it's a feeling, and it doesn't tell us anything useful about tradeoffs. We ask what's actually driving the date: a trade show, a funding round, a rebrand launch tied to a press announcement that's already scheduled. A real deadline with a real reason changes what we recommend cutting from the first version far more usefully than an arbitrary one does.

When there's no real external deadline, we say so, because an artificial urgency usually produces worse decisions on both sides. Rushed projects tend to cut corners in ways that show up later as support tickets, and a client is better served by an honest timeline than by a falsely aggressive one that neither side can actually hold to.

Existing brand guidelines, a CRM the sales team is attached to, an email platform with years of automation built into it: these constraints matter as much as anything we'd design from scratch, and they're easy to miss if we don't ask directly. We've had projects where a client assumed a tool would obviously be replaced, and others where the same tool was treated as sacred, with no way to know which without asking.

We also ask what's explicitly not up for debate, separate from what's merely preferred. A client who says "we're not changing our logo" needs a different conversation from one who says "we like our current logo" but would consider changes if we made a strong case. Confusing the two leads to wasted design rounds on either side.

This is the question that separates a project from a purchase. A client focused on launch day alone tends to under-invest in the things that matter afterward: analytics setup, a content plan, a maintenance budget. Asking about six months out surfaces whether they're thinking about the site as an asset that needs tending or a deliverable to check off a list.

The answer also tells us what to measure. If success is lead volume, we build in tracking and conversion points from day one instead of bolting them on later. If success is simply having a credible presence to point partners to, that changes the entire design brief, and pricing that difference in wrong assumes we know which one we're building toward.

We tried a scoping questionnaire early on, hoping to save time on both sides before a call. It backfired: answers came back short and generic, because a form invites a minimum-effort response in a way a real conversation doesn't. "What does the site need to do" answered in a text box became "generate leads," with none of the follow-up detail a live conversation naturally pulls out.

A conversation lets us ask the obvious follow-up the moment a vague answer shows up, instead of discovering the gap days later when we're already halfway through writing a proposal. It takes longer per client, but it produces answers we can actually build a number on, which saves far more time than the questionnaire ever did.

Sometimes the honest answer to one of these five questions is "I don't know yet," and that's a legitimate answer, not a failure to prepare. When that happens, we don't force a number. We scope a smaller, paid discovery phase instead, specifically aimed at answering the open questions before committing either side to a full project quote.

This has saved several relationships that would otherwise have started on a shaky number neither of us could really stand behind. A short discovery engagement costs a client far less than a full project quoted on guesses, and it usually produces a better project besides, because the resulting scope reflects answers instead of assumptions.

A proposal built on real answers reads differently than a templated one. Ours name the specific pages, the specific integrations, the specific maintenance plan discussed on the call, in the client's own language wherever possible. Clients notice the difference immediately, and it's usually the moment a prospect stops shopping around and starts trusting the number in front of them.

It also means our proposals are harder to directly compare to a competitor's generic one line-by-line, because ours has more specific detail attached to each line. We've found that specificity, more than price, is what actually wins trust at this stage, even when our number isn't the lowest one on the table.

None of these questions are hard to ask. What's hard is resisting the pressure to skip them and produce a number quickly, because clients often want speed more than they realize they want accuracy, right up until the moment a quote turns out to be wrong.

A quote built on real answers to these five questions takes a day or two longer to produce than one built on a template. It's also a number we can actually stand behind once the project starts, which matters more to both sides than shaving a day off the proposal turnaround.