Briefing a web developer so you get the site you need.

Most website projects that go wrong start with a vague brief. A developer can't quote accurately, you can't compare proposals fairly, and six months later you're stuck with a site that doesn't do what you needed.

A good brief doesn't need to be long. It needs to be clear. Here's how to write one that gets your Norfolk business the website you actually want, without the back-and-forth.

Start with what the site needs to do

Don't start with colours or fonts. Start with jobs. What does this website need to achieve for your business?

• Take bookings for your Norwich gym or clinic?
• Sell products to trade customers across the UK?
• Generate enquiries for your surveying or consultancy practice?
• Explain a complex service so customers understand what you offer before they call?

Write down the top three things the site must do. Everything else flows from that.

List the pages and features you know you need

You don't need a full sitemap, but a rough list helps. For example:

• Homepage
• About page
• Services (maybe one page per service)
• Case studies or portfolio
• Contact page with a form
• Blog (if you'll actually use it)

Then add any features that matter: online booking, a quote calculator, a members' area, e-commerce with 50 products, integration with your CRM. Be specific. "E-commerce" could mean anything from a donate button to a wholesale platform with custom pricing per account.

Explain who the site is for

A developer needs to know your audience. A site for Norwich cafes ordering custom packaging looks nothing like a site for homebuyers booking a building survey.

Write a paragraph about your typical customer. What do they need to know before they buy? What questions do they always ask? What puts them off? If you have two or three distinct audiences (say, trade buyers and retail customers), call that out.

A brief that says "make it modern and professional" tells a developer nothing useful.

Show examples of sites you like (and why)

Find three or four websites you think work well. They don't need to be in your industry. For each one, write a sentence about what you like: the layout, the tone of the copy, the way the contact form works, how easy it is to find pricing.

This gives a developer a sense of your taste and expectations. It's much more useful than "make it look premium" or "keep it simple".

Be honest about content

Will you write the copy, or does the developer need to? Do you have professional photos, or will you need a shoot? Do you have your logo as a vector file, or just a JPG pulled off your old site?

If you're not sure, say so. A developer can help, but they need to know what's missing so they can quote for it or point you to someone who can.

Set a realistic budget range

You don't need to name a figure, but a range helps. A five-page brochure site for a Norfolk trades business costs less than a wholesale e-commerce platform with account management and API integrations.

If you say your budget is £2,000 but your brief describes a £15,000 project, a good developer will tell you. If you don't mention budget at all, you'll get proposals that range from £1,500 to £25,000 and you won't know why.

Include a rough timeline

When do you need the site live? Is there a specific reason (a trade show, a rebrand, the end of your current hosting contract), or is it flexible?

If you need it in six weeks, that's fine, but it will shape what's possible. If you're planning for three months' time, say so. A developer can schedule the work properly and tell you if your timeline is realistic.

Add any technical details you know

Do you already have hosting, or does the developer need to arrange it? Do you need the site to integrate with your booking system, Xero, Mailchimp? Do you want to be able to edit content yourself, or are you happy to ask the developer to make changes?

If you don't know the answers, that's fine. But if you do, include them. It saves a lot of questions later.

What a good brief gets you

A clear brief means you'll get accurate quotes you can actually compare. It means the project starts faster, because the developer isn't spending the first two weeks asking follow-up questions. And it means you're far more likely to get a site that does what you need, because you've told them what that is.

It doesn't need to be formal. A few pages in a Google Doc is fine. Just make sure it answers the questions above, and you'll save yourself a lot of time and money.