Most web projects don't fail because of bad code. They fail because nobody agreed on what the project was actually supposed to accomplish before the work started.

A client says they want a new website. A developer nods, opens a text editor, and starts building. Six weeks later, the client sees the first draft and says "this isn't what I had in mind." Now everyone's frustrated. The developer thinks the client is moving goalposts. The client thinks the developer didn't listen. They're both right, in their own way.

I've been on both sides of that conversation. The fix is straightforward: ask the right questions before anything else.

Here's what I ask every client, and what I'm actually listening for when they answer.

"What problem is this project solving?"

Not "what do you want built" — what problem does it solve.

A business that wants a new website might actually need better lead conversion. A company that wants a client portal might actually need to stop losing track of projects in email threads. A startup that wants an app might actually need to validate whether anyone wants the thing before spending $50,000 building it.

The stated request and the actual problem are often different. If I build what someone asks for without understanding the underlying problem, there's a real chance I build the wrong thing very well.

"Who is using this, and what do they already know?"

Every decision about a project — what to show, how to organize it, how complex the interface can be — depends on who's on the other side of the screen.

A client portal for accountants can assume financial literacy and comfort with data-dense layouts. A public-facing form for homeowners requesting quotes needs to assume nothing and make every step obvious. These are completely different projects even if they look similar on a feature list.

I'm also listening for assumptions the client makes about their users. Sometimes a business owner is convinced their customers are tech-savvy when the actual data suggests otherwise. Knowing who the real user is — not the imagined one — changes everything about the design.

"What does success look like in six months?"

I want a number, or at least something measurable. "More leads" isn't a success metric. "Twenty qualified inquiries per month" is.

When clients can tell me what winning looks like, I can make decisions that move toward that outcome. I can also flag when a requested feature doesn't contribute to it, which happens more often than you'd think.

If a client can't answer this question, that's useful information too. It means we need to slow down and define success before we start building anything.

"What do you hate about what you have now?"

This is one of the most productive questions I ask, because the answer is almost always specific.

"It's slow." "It doesn't work on my phone." "I can't update it without calling someone." "It looks like it was built in 2012." "It never shows up when people search for us."

These complaints tell me more about the actual requirements than any feature list would. They also tell me which problems the client is most motivated to solve, which helps when it's time to make tradeoffs about scope or budget.

"What's the real deadline?"

There's always a stated deadline and a real one. "We'd like it done by end of quarter" and "we have a product launch on May 15th that this needs to be live for" are very different situations.

I ask this not to challenge the timeline but to understand the consequences of missing it. If there's a hard external date — an event, a launch, a contract — I need to know that upfront so I can structure the project around it. If the timeline is flexible, I can prioritize getting things right over getting things done fast.

I also push back when a timeline isn't realistic. Telling a client "that's not enough time to do this properly" early is far less painful than delivering something half-baked on a deadline.

"What's your budget range?"

This one makes people uncomfortable, but it matters. Budget determines what's possible.

A $5,000 project and a $30,000 project can have the same stated requirements. The difference is depth — how much discovery, how much polish, how much custom functionality, how much testing. Without knowing the range, I can't give a realistic proposal. I end up either over-promising or under-scoping.

I'd rather have an honest conversation about budget upfront than propose something the client can't afford — or deliver something that didn't meet expectations because the scope wasn't right.

Why this matters

None of these questions are particularly complicated. What's uncommon is that most developers skip them, because asking questions feels like slowing down and clients want to feel like things are moving.

But the fastest path to a good outcome isn't starting immediately. It's starting in the right direction. An hour of honest conversation upfront saves weeks of revisions later.

If you're thinking about a web project and want to talk through the details — not a sales pitch, just a real conversation — reach out. These are the kinds of questions I'd want to answer with you before anything else.