The Discovery Questions I Ask Before Starting Every Web Project

I used to dive straight into wireframes and tech stacks. Client says they need a website? Great, let’s talk about design and features.

That approach led to scope creep, misaligned expectations, and websites that looked good but didn’t actually help the business. Now I spend the first conversation asking questions that have nothing to do with the website itself.

Most clients don’t actually know what they need. They know they need “a website” or “a redesign,” but that’s the solution, not the problem. My job is to figure out what problem we’re actually solving.

The Questions That Actually Matter

1. What’s Not Working Right Now?

This is where I start. Not “what do you want?” but “what’s broken?”

Sometimes it’s obvious: “Our site is from 2012 and doesn’t work on phones.” Other times it’s more subtle: “We’re getting traffic but nobody’s contacting us” or “Our team can’t update content without calling our old developer.”

The answer tells me whether this is a cosmetic refresh, a technical rebuild, a conversion problem, or something else entirely.

Why this matters: If they can’t articulate the problem, we’re probably solving the wrong thing. A new website won’t fix unclear messaging or a broken sales process.

2. What Do You Want the Website to Do?

Not what it should look like, but what job it is actually doing.

Take enquiries. Take bookings. Sell products. Qualify leads before they reach you. Give existing customers somewhere to find answers so they stop ringing. Prove you are a real business to someone who found you on Google at 9pm.

Most sites are asked to do three or four of these at once, and they are rarely equally important. Knowing the order changes nearly every decision that follows, from what sits above the fold to whether a booking system is worth the money.

Why this matters: “A website” is not a goal. If the honest answer is “get more enquiries from Perth tradies”, I can build for that. If it is “look more professional than our competitor”, that is a real answer too, and it points somewhere completely different.

3. What Does Success Look Like in 6 Months?

Not “what features do you want” but “what business outcome do you need?”

Good answers sound like:

“We need 30 qualified leads per month”
“We need to reduce support calls about basic product info”
“We need to rank on page one for [specific terms]”
“We need to book 20 consultation calls a month”

Bad answers sound like:

“We need it to look modern”
“We need to use the latest technology”
“We want people to be impressed”

Why this matters: Vague goals lead to vague results. If we don’t know what we’re measuring, we can’t tell if the project succeeded.

4. Who Actually Needs to Use This?

Not “who’s your target market” but specifically: who needs to do what on this website?

I’m looking for concrete scenarios:

“Property managers need to see available units and book viewings”
“HR teams need to download compliance documents”
“Homeowners need to request quotes and see past work”

Why this matters: Generic “everyone needs to navigate easily” doesn’t help me prioritize. Specific user needs drive specific design decisions.

5. What Happens After Someone Contacts You?

This question catches people off guard, but it’s crucial.

If someone fills out the contact form, then what? Does it go to a shared inbox? Does someone respond within an hour or within a week? Is there a CRM? A follow-up process?

Why this matters: I’ve seen beautiful websites that generate leads that go into a black hole. The website is just one part of the system. If the follow-up process is broken, the website can’t fix that.

6. Who’s Actually Going to Maintain This?

Not “will you maintain it?” but specifically: who on your team will update content, add blog posts, change service descriptions?

I need to know:

Their technical skill level (can they handle markdown? HTML? or just visual editors?)
How often they’ll need to update things
Whether they have time and buy-in to actually do it

Why this matters: If nobody on their team will maintain it, we need to either plan for that (ongoing maintenance contract) or keep the CMS extremely simple. Building something they can’t use is a waste.

7. What Content Actually Exists?

Do they have:

Professional photos or are we using stock images?
Written service descriptions or do those need to be created?
Case studies, testimonials, or portfolio work documented?
A clear idea of their core message and value proposition?

Why this matters: “Content is coming” is the death of timelines. If they don’t have content ready, we need to either plan for content creation or acknowledge that launch will wait.

8. Do You Have Brand Guidelines, and Are You Happy With Them?

Two questions in one, and the second matters more.

Plenty of businesses have a logo and a colour someone picked in 2014, and no real system underneath. Others have a full brand kit they have never liked. Both are worth knowing before design starts, because building a site on a brand the client quietly resents means redoing it in eighteen months.

If the brand is solid, I work to it. If it needs attention, I would rather say so early and bring in someone who does that properly. I work alongside some genuinely good designers and brand people, and a site built on considered brand work is a different thing entirely from one built on a logo and a guess.

Why this matters: Design decisions cascade. Fonts, colour, tone and imagery all flow from the brand, and reversing those halfway through a build is expensive. It is also the difference between a site that looks like the business and one that looks like a template.

9. What’s the Honest Budget and Timeline?

Not “what would you like to spend” but “what’s actually approved and available?”

And more importantly: what’s driving the timeline? Is there a trade show? A funding round? Or is it just “sooner is better”?

Why this matters: Mismatched expectations on budget and timeline kill projects. If they have $5,000 and need it in 3 weeks, we can’t build a custom e-commerce platform. Better to know that now.

10. What Websites Do You Actually Like (And Why)?

I ask them to show me 3-5 websites they think work well. Not necessarily in their industry.

Then I ask: what specifically do you like? The design? The copy? The way they explain their services? How it works on mobile?

Why this matters: This reveals their taste, their expectations, and often uncovers requirements they hadn’t articulated. If they love sites with heavy animation and their budget is $3,000, we have a problem to address early.

11. What Are Your Competitors Doing?

I ask them to show me 2-3 competitor sites and tell me:

What are they doing well?
What are they doing poorly?
Where’s the opportunity for you to be different?

Why this matters: I need to understand the competitive landscape. Sometimes the answer is “match what they’re doing but execute better.” Sometimes it’s “go in a completely different direction.”

12. What Keeps You Up at Night About This Project?

This is where the real concerns come out.

“I’m worried it’ll take too long.” “I’m worried we’ll spend money and it won’t generate leads.” “I’m worried our team won’t be able to use it.” “I’m worried it’ll look cheap.”

Why this matters: These concerns need to be addressed in the proposal and throughout the project. If I don’t know what they’re worried about, I can’t reassure them or build in the right safeguards.

Questions I Don’t Ask (And Why)

“What features do you want?” - Too early. Features are the solution, not the requirement. I need to understand the problem first.

“What’s your brand personality?” - Too abstract. Most people can’t answer this clearly. I’d rather see their existing materials and have a conversation about audience and tone.

“What CMS do you want?” - They shouldn’t care. That’s my job to recommend based on their needs and team’s capabilities.

What This Actually Looks Like

This isn’t a formal questionnaire. It’s a conversation, usually 60-90 minutes, sometimes over two calls.

I’m taking notes, asking follow-up questions, and trying to understand not just what they’re saying, but what they’re not saying. Sometimes what actually matters is buried three questions deep.

By the end, I should understand:

The business problem we’re solving
What success looks like (with numbers)
Who will use it and how
What their team can realistically maintain
What’s driving the timeline and budget
What concerns need to be addressed

What Happens After Discovery

Then - and only then - do I talk about approach, tech stack, design direction, and timeline.

Because now I know whether they need:

A simple 5-page site with a contact form
An extensive service site with lots of content and SEO focus
A lead generation machine with sophisticated forms and CRM integration
A content platform their team will regularly update

Discovery isn’t about checking boxes. It’s about understanding enough to recommend the right solution, price it accurately, and deliver something that actually achieves their goals.

The Bottom Line

Most project failures start at the discovery phase. Either it doesn’t happen at all, or it focuses on the wrong things (features and aesthetics instead of business outcomes).

The questions I ask aren’t revolutionary. But taking the time to ask them - and actually listening to the answers - prevents almost every problem I used to encounter: scope creep, timeline slips, unhappy clients, and websites that look nice but don’t deliver value.