Contents
The most expensive mistake in web development isn't a technical one. It's starting a project without clear answers to the questions that determine whether the project is worth doing and how it should be built.
Developers — including me — share responsibility for this. It's easier to take a brief at face value and start building than to push back and force a harder conversation. But a website built on an unclear brief will produce unclear results, and you'll end up rebuilding sooner than you should.
Before you spend anything on a website, get clear on these three things.
Question 1: Who is this for, and what do they need to believe?
"Our customers" isn't an answer. "Small business owners in the construction trades who are skeptical of tech vendors because they've been oversold before" is an answer.
The more specifically you can describe the person landing on your site, the more precisely you can build for them. What do they already know? What are they worried about? What would make them trust you enough to reach out?
A website that's built for a specific person makes very different decisions than one built for a vague "general audience." The headline speaks to a specific pain. The testimonials address specific doubts. The call to action feels like the logical next step for someone who has that specific problem.
If you can't describe the person you're building for in two or three sentences, you're not ready to start. Spend thirty minutes writing a profile of your best current client — what they were worried about before they hired you, what convinced them to reach out, what they got that they didn't expect. That profile is your target user.
Question 2: What's the one thing you want someone to do?
There's a tendency to want a website to do many things: generate leads, show the portfolio, build the email list, describe all ten services, explain the company story, and maybe sell some merchandise.
Websites that try to accomplish everything usually accomplish nothing well. The visitor lands, sees many options, defaults to the least commitment — scrolling — and leaves.
Pick one primary action and build the site around it. For most service businesses, that action is "contact us" or "schedule a call." For SaaS companies, it's usually "start a trial." For content businesses, it might be "subscribe."
Every other element of the site should support that action or at least not undermine it. Navigation that leads visitors away from conversion, five different calls to action competing for attention, a homepage that tells your company history before it answers "can you help me" — these are design choices that work against the one thing you want people to do.
Question 3: How will you know if it's working?
Most business owners can't answer this question, which means they can never know whether their website is succeeding or failing.
"More traffic" isn't a measure. Traffic is a means to an end. The end is inquiries, leads, calls, sales — some form of business outcome. Define what success looks like in specific, measurable terms: "Ten qualified leads per month from organic search" or "Three calls booked per week from the website" or "Twenty percent of visitors who land on the pricing page reach out."
Knowing what success looks like does two things. First, it gives you a basis for making decisions about design, content, and investment. Second, it tells you when the site isn't working so you can fix it instead of assuming the problem is somewhere else.
Before any project starts, define the metrics you'll track and the baseline you're measuring against. If you don't have analytics installed on your current site, do that today — even if you're not ready to act on the data yet. You need the baseline before you can measure improvement.
Why this matters before you talk to a developer
A developer who gets clear answers to these three questions can make intelligent decisions throughout the build. They know who they're designing for. They know what action to optimize around. They know what "successful" means for the project.
A developer who doesn't have these answers will fill in the blanks themselves — and their answers might be different from yours.
The most aligned web projects are the ones where the business owner and the developer have the same clear picture of who the site serves, what it needs to do, and how they'll know it's working. Getting to that shared picture is worth whatever time it takes.
Once you have answers, the next step is putting them into a brief your developer can actually use. If you want to work through these questions before starting a project, reach out. It's the most useful conversation we could have.