The gap between what a client means and what a developer hears is where most of the frustration, wasted time, and unexpected cost in web projects comes from. The good news is that it's almost entirely avoidable. You don't need to learn to code. You don't need to study design theory. You just need to know what information actually matters to the person building your site, and how to communicate it in terms they can act on.
This article is about bridging that gap. Whether you're working with a sole developer, a small studio, or a full-service agency, these principles will make the process smoother, the result closer to what you had in mind, and the whole experience significantly less painful for everyone involved.
The single most useful thing you can tell a developer is why you need a website, not what you want it to look like. There's a crucial difference.
"I want a website with a slider on the homepage, a services page with icons, and a contact form in the footer" is a solution. It tells the developer what to build, but not why. They'll build exactly that, and if the slider doesn't actually help your visitors find what they need, or the icons confuse more than they clarify, nobody will catch it until it's too late. The developer built what you asked for. You asked for the wrong thing. Nobody's happy.
"We're a solicitors' firm and most of our new clients come through referrals, but we want the website to help convert people who find us through Google. They need to trust us quickly and it needs to be very easy to get in touch." That's a problem. It gives the developer something to solve. Now they can make informed decisions about layout, content hierarchy, calls to action, and page structure, all in service of that goal. If they suggest something you hadn't thought of, like a click-to-call button that's visible on every page for mobile users, it's because they understood what you're trying to achieve, not just what you told them to build.
Before your first meeting with a developer, spend ten minutes writing down the answers to three questions: What does your business do, in plain terms? What do you want this website to achieve? And what's not working about what you have now (or why don't you have anything)? Those three answers will do more for the success of your project than any mood board or wishlist.
Language is imprecise. "Modern" means something different to a 28-year-old designer than it does to a 55-year-old solicitor. "Clean" could mean minimalist with lots of white space, or it could mean well-organised with everything easy to find. "Professional" is so broad as to be almost meaningless. These words come up in every single web project, and they cause misunderstandings in most of them.
The fix is simple: show examples. Before you meet with your developer, spend half an hour browsing websites, and not just in your own industry. Look at sites you like and sites you don't. Pay attention to what specifically appeals to you or puts you off. Is it the way the navigation works? The amount of text versus imagery? The colour palette? The way the site feels when you scroll through it?
Bring three or four examples to the conversation and be specific about what you're pointing to. "I like this site" isn't helpful. "I like how this site uses large photography but doesn't feel cluttered, and I like that the contact information is always visible in the header" is extremely helpful. Equally, "I don't like this site because the text is too small and there's too much happening on each page" tells your developer exactly what to avoid.
What you dislike is often more valuable than what you like. A developer can work around your preferences. What they can't do is read your mind when you look at their first draft and feel vaguely dissatisfied without being able to explain why. Giving them your dislikes upfront eliminates entire categories of wrong turns.
Business owners naturally talk about their business when briefing a developer. What they do, how long they've been doing it, what makes them different. All of this matters. But what often gets missed, and what matters just as much, is who their customers are and how those customers behave online.
A building contractor whose clients are mostly architects and project managers needs a very different website from a contractor whose clients are homeowners looking for an extension. The first audience wants credentials, technical capability, and case studies. The second wants reassurance, clear pricing, and examples they can relate to. If your developer doesn't know which audience they're designing for, they'll make assumptions, and assumptions are where projects drift.
Think about your typical customer's journey. How do they find you? What do they need to know before they're ready to get in touch? What objections or hesitations do they have? What's the first thing they'd want to see on your site? If you can answer these questions, your developer can build a site that's structured around how real people actually make decisions, rather than one that's structured around how your business is internally organised.
Here's a tell: if your website's navigation mirrors your company's internal departments rather than the questions your customers ask, your developer didn't have enough information about your audience. That's a briefing problem, not a design problem.
Content is where most web projects stall. The design is approved, the build is underway, and then everything stops because the client hasn't provided the text, the images, the team bios, or the case studies they said they'd have ready by week three.
This is so common that developers plan for it. They factor in content delays the way builders factor in rain.
Be upfront about this from the start. If you don't have the copywriting done, say so. If you don't have professional photography and weren't planning to get any, say that too. If you know you'll struggle to find time to write your own content, be honest about it. A good developer would rather know this in the first meeting than discover it halfway through the build, because it changes the timeline, the quote, and possibly the approach.
If you can provide real content (even rough drafts) before the design phase begins, you'll get a dramatically better result. Designers and developers working with placeholder text are guessing at how much space things need, how the page will flow, and what the visual balance should be. Real content, even imperfect content, gives them something truthful to build around.
Every client has things that absolutely must be right. For one business, it's that the booking system integrates with their existing calendar software. For another, it's that the site loads fast on mobile because their customers are mostly on their phones. For a third, it's that the design matches their existing printed materials exactly.
Name these upfront. Tell your developer, clearly and early, what the dealbreakers are. The things that, if they're wrong, the project has failed regardless of how good everything else is. These are your non-negotiables, and your developer needs to know them before they start, not after they've built something that doesn't account for them.
Everything else? Be open to your developer's judgment. If you've hired someone with experience, let them bring that experience to the table. A common pattern in web projects is a client specifying exactly how every element should look and behave, which leaves no room for the developer to apply what they know about usability, performance, and what actually works in practice.
The best projects tend to have a clear brief on the "what" and the "why" but leave the "how" largely to the professional. You wouldn't tell your electrician which gauge of wire to use. You'd tell them what you need the room to do, and trust their expertise on the technical execution.
Nobody likes this bit. But avoiding the budget conversation upfront causes more problems than having it.
Developers aren't trying to spend as much of your money as possible. They're trying to work out what's achievable within your constraints. A developer who knows you have £3,000 will design a project that's realistic for £3,000. A developer who doesn't know your budget will either over-scope something you can't afford (wasting both your time) or under-scope something that doesn't meet your needs (because they assumed you wanted the cheapest option).
You don't need to give an exact figure. A range is fine. "We're hoping to spend between three and five thousand" is enough information for any competent developer to shape a proposal that fits. What doesn't help is "we don't have a budget," because everyone has a budget, even if it's defined by the point at which you'd walk away. And it really doesn't help to hide your budget in the hope of getting a lower quote. Good developers price based on the work involved, not on what they think you can afford.
If your budget and your wishlist don't match, a good developer will tell you. They'll explain what's realistic for the money and help you prioritise. That conversation is one of the most valuable things a developer can offer, but it can only happen if you're both being straight about the numbers.
This one sounds trivial. It isn't.
Projects get messy when feedback, requests, and approvals are scattered across emails, phone calls, text messages, WhatsApp threads, and the occasional passing comment at a networking event. Important details get lost. Decisions get made in one channel and contradicted in another. The developer spends time hunting through conversations looking for that thing you mentioned about the footer last Tuesday.
At the start of a project, agree on a single primary channel for project communication. Email works for most people. Whatever you choose, the principle is the same: keep everything in one place so nothing falls through the cracks and there's a clear record of what was agreed.
The other thing worth agreeing upfront is how feedback will work. When the developer sends you a draft to review, how long will you take to respond? Will one person from your side give consolidated feedback, or will the developer receive separate opinions from three different people in your business? (The second scenario is a recipe for chaos. Nominate one person with decision-making authority and let them collate everyone's input before responding.)
There are no stupid questions in a web project. There are only unasked questions that turn into expensive problems later.
If your developer proposes something and you don't understand why, ask. If they use a term you're not familiar with, ask what it means. If they recommend an approach and you're not sure what the alternatives are, ask them to explain the trade-offs. A good developer welcomes questions because they show you're engaged and because they surface misunderstandings before they become built into the site.
Some useful questions to have in your back pocket: Why have you recommended this approach over alternatives? What happens if we need to change this later? How will this work on a phone? What ongoing maintenance will this need? What happens to the site if we stop working together?
That last question is particularly worth asking. The answer tells you a lot about how the developer thinks about your long-term interests versus their own convenience.
Perhaps the biggest misconception in web development is that the brief is a fixed document you hand over at the start and the developer builds exactly what it describes. In practice, the best projects treat the brief as a starting point for an ongoing conversation.
As the project progresses, you'll see things you hadn't anticipated. The developer will suggest improvements you hadn't considered. Your understanding of what you need will evolve as the site takes shape. This is healthy. It's not scope creep. It's the natural result of two people working together to solve a problem that neither fully understood at the outset.
The key is keeping the communication open. If something's bothering you, say it early rather than waiting until the final review. If the developer spots a better way to handle something, you want to hear about it while there's still time to adjust. The projects that produce the best results are the ones where the client and developer talk frequently, honestly, and without defensiveness on either side.
Here's the thing that took me years to fully appreciate: the quality of the brief matters more than almost any other factor in a web project. A great developer with a bad brief will produce a mediocre result. A decent developer with a great brief will produce something genuinely good. The brief is where the value is created or lost.
And the brief isn't just the document. It's the relationship. It's whether the developer understands your business well enough to make good decisions on the hundred small things you'll never be consulted on. It's whether you trust them enough to be honest about your budget, your constraints, and the things you don't know. It's whether the two of you can have a straightforward conversation when something isn't working.
At Pedwar, every project starts with this kind of conversation. There's no account manager relaying your words to someone else. The person you talk to is the person who builds your site, which means nothing gets lost in translation and the context of every decision you make together stays in the room for the life of the project. That direct relationship is, in my experience, the single biggest factor in whether a website turns out well.
But regardless of who builds your next site, the principles in this article apply. Brief well, communicate clearly, and stay involved. Your developer will thank you, and your website will be better for it.
We're proud to have been recognised as Wales' Most Trusted Web Design & Development Company for 2025. This award reflects our commitment to delivering exceptional digital solutions and outstanding client service that sets the standard for excellence.
