A website project rarely goes wrong because a developer cannot write the code. It goes wrong because the business has not made clear what the website needs to achieve. Knowing how to brief a web developer means turning broad aims such as “we need a better website” into decisions they can build, test and measure.

A good brief protects your budget, reduces delays and makes it far more likely that the finished site will generate enquiries, sales or the other outcomes that matter to your business. It does not need to be a 40-page document. It does need to be specific enough to stop assumptions taking over.

Start with the commercial problem, not the design

Before discussing colours, page layouts or features, explain why the project is happening now. Perhaps your current site is difficult to update, does not work well on mobile, attracts the wrong type of enquiry or fails to support your sales team. Those are useful starting points because they give the developer context.

Set out the one or two commercial outcomes the new website must support. For a local service business, that may be more qualified calls and quote requests. For an eCommerce business, it may be improving conversion rate, average order value or the ability to manage stock properly. An established company may need a clearer proposition that helps its team win larger contracts.

Avoid vague measures such as “make it more modern”. A modern-looking site that is slow, unclear or difficult to find in search will not solve much. If appearance is part of the problem, explain what is not working: perhaps the site feels dated compared with competitors, key services are buried, or the branding no longer reflects the level at which you operate.

How to brief a web developer with clear goals

Your developer needs a definition of success. This should include what you want visitors to do and how you will judge whether the project is working after launch.

For example, you may want users to submit a form, book a consultation, call the office, request a brochure, buy online or visit a particular location. Give each action a priority. If phone calls are your best source of leads, the mobile call button and call tracking deserve more attention than a newsletter sign-up.

It also helps to share the numbers you have. Current monthly traffic, enquiry volumes, conversion rates, average order values and sales cycle length all provide a useful benchmark. You do not need perfect data. Honest data is better than optimistic guesswork, and it helps shape sensible decisions around pages, functionality and tracking.

Be realistic about what a new website can change on its own. Better user journeys, stronger messaging and faster pages can improve conversion. They will not automatically create demand if nobody can find the site. If search visibility and paid traffic are part of the growth plan, make that clear at the start so the build supports SEO, PPC landing pages and accurate reporting.

Explain your customers and how they buy

A developer does not need a full marketing strategy document, but they do need to understand the people using the site. Describe your main customer types, the problems they are trying to solve and the questions that usually arise before they contact you.

A commercial buyer may need proof that you can handle a complex project, while a homeowner may want price guidance, reassurance and a quick way to get in touch. Both may end up on the same website, but they should not necessarily see the same journey or content first.

Include practical detail. Say whether most visitors are on mobile, whether they tend to call during working hours, whether decisions involve several people, and whether enquiries need to be routed to different teams. These details influence navigation, page structure, forms and calls to action.

Competitor examples can help, but use them carefully. Show what you like or dislike about them rather than asking for a copy. A developer can learn from a competitor’s clear navigation or useful product filters. Copying their design without understanding their audience usually produces a site that looks familiar but says little about your own business.

Define the scope before discussing the price

Scope is the part of the brief that prevents a fixed price turning into an open-ended project. List the pages you expect, the functions required and any systems the website needs to connect with. If you are unsure, say so. A good developer should help you work through it, but they cannot price a blank space.

The following details are worth setting out clearly:

• the pages and service, product or location sections you expect to launch with
• functions such as booking, quoting, product filtering, customer accounts or online payments
• integrations with a CRM, email platform, accounting system, stock system or third-party software
• who needs access to update the website and what they need to change
• any existing content, images, brand guidelines or photography that can be reused

Separate must-haves from nice-to-haves. A properly working enquiry process, a manageable content system and reliable analytics may be essential. An interactive calculator or complex customer portal may be valuable, but could be better handled as a later phase. This is not about cutting corners. It is about investing first in the work that has the clearest commercial impact.

If you sell online, be especially clear about products, variants, delivery rules, VAT, returns, discounts and stock management. These are not minor details. They affect the platform, development time and day-to-day workload after launch.

Be honest about budget and timescales

Many businesses hold back their budget because they worry every supplier will simply quote up to it. That concern is understandable, but a credible budget range lets a developer recommend the right approach. A £5,000 build and a £25,000 build may both be called a website, but they will not involve the same discovery, design, functionality, testing or content support.

You do not need to disclose a final figure if it has not been approved. A working range is enough. It allows the developer to flag what is feasible now, what should be phased and where a cheaper route may create problems later.

Timescales need the same honesty. If the site must launch before a trade event, campaign or company milestone, state the date and the reason. Then discuss what is required from your side. Development is often held up by late content, delayed feedback or uncertainty over legal approval, not by coding.

A rushed launch can be the right choice if there is a genuine commercial deadline. It may mean reducing the first-phase scope rather than trying to build every feature at once. What matters is making that trade-off consciously.

Agree content ownership and decision-making

Content is often the biggest hidden risk in a web project. Developers can create page templates, but they cannot reliably write specialist service copy, approve technical claims or supply original images without input from the business.

Your brief should say who is responsible for copy, photography, product data, legal wording and brand assets. If an agency is creating content, confirm how much is included and who signs it off. If your internal team is supplying it, set realistic deadlines and nominate one person to chase it.

You should also name the person with final authority to approve work. Too many projects become stuck because feedback arrives from six people with different opinions. Wider input can be useful, particularly from sales, operations and customer service. But one person needs to consolidate feedback and make a decision when views conflict.

Ask for a clear approval process. You should know when you will review the sitemap, page designs, development build and testing version, and what happens if you request changes outside the agreed scope. That is not needless paperwork. It keeps the relationship straightforward and stops small requests quietly becoming a major cost or delay.

Cover the practical details that protect the website

A website is not finished when it goes live. Your brief should cover hosting, domain access, maintenance, backups, security updates and support after launch. Clarify who owns the website files, platform accounts and third-party licences. You should never be locked out of systems that are central to your business.

Ask how the site will be tested across mobile, tablet and desktop, and whether key forms, checkout journeys and tracking will be checked before launch. Accessibility should also be part of the discussion. Clear navigation, readable content and usable forms benefit more people and reduce avoidable barriers to conversion.

Finally, make sure analytics, consent settings and conversion tracking are included in the plan. Without reliable tracking, it is difficult to tell whether the website is improving lead quality or simply receiving more visits. This matters even more when SEO and Google Ads activity will drive traffic after launch.

A strong brief does not remove every question from a website project. It gives the right questions a place to be answered before they become expensive problems. Be clear about the outcome, honest about constraints and decisive about priorities. That gives your developer the information needed to build a website that earns its place in the business.