How to Brief a Web Developer: The Questions That Save You Time, Money and Headaches

What a good brief actually does

A good brief answers four questions before anyone writes a line of code: what are we building, who owns the words and images, who controls the keys (hosting and domain), and who owns the finished site once it's live. Get those four nailed down and most of the horror stories you've heard about web projects simply can't happen to you.

Most scope creep and surprise invoices don't come from dishonest developers. They come from vague briefs. "We need a modern website for our business" tells a developer almost nothing. It doesn't say how many pages, what the site needs to do, who's writing the content, or what happens after launch. Every gap in a brief becomes a conversation later, usually a paid one. This guide walks through the questions worth settling upfront, whether you're commissioning your first web design and development project or you've been burned before and want to do it properly this time.

Scope: say exactly what the site needs to do

Scope is the single biggest source of disputes in web projects, and it's entirely avoidable. A proper brief lists the pages, the features and the behaviours you expect, not just a vague description of the business. If you need a booking form, say so. If you need the site to work well on phones, say so. If you need it to load quickly, say so. None of this is pedantry, it's the difference between a fixed price you can trust and a project that balloons.

Three areas are worth spelling out explicitly, because they're easy to assume and expensive to retrofit:

• Accessibility. Decide what standard you want met and say it in the brief. Google's own web.dev resource runs a dedicated Learn Accessibility course aimed at making sites usable by everyone, which is a sensible benchmark to point your developer towards even if you're not legally required to meet a specific standard. If you run a public sector body, this isn't optional: since the Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations 2018 came into force, every new public sector website has had to meet certain accessibility standards and publish a statement confirming it. Government guidance goes further, recommending that any tender for website work explicitly require WCAG 2.1 AA compliance and a published Accessibility Statement, and that suppliers show evidence of accessibility testing from previous projects. Meeting WCAG 2.2 at AA level is currently treated as the working benchmark for public sector compliance and for Equality Act compliance more broadly, according to Level Access's summary of UK accessibility law. Put the standard you want in writing, whatever sector you're in.
• Speed and performance. A slow site loses visitors before they've seen anything. web.dev frames performance as a core part of user experience in its Learn Performance course, and it's worth asking your developer how they test for speed rather than assuming it'll be fine.
• Responsive design. Your site has to work on a phone, a tablet and a laptop, often in that order of importance. web.dev's Learn Design course covers the responsive principles that make a site usable across devices. A brief that just says "responsive" without checking the developer actually tests on real devices is only half a brief.

None of this needs technical language from you. You just need to say what matters and ask how they'll deliver it.

Content ownership: who writes it, who approves it, who owns it

Before any design work starts, agree who is writing the words, sourcing the photos and approving each page before it goes live. This sounds obvious, but it's the stage where projects quietly stall for weeks because nobody was ever clearly responsible for the copy. A brief should state plainly: client provides text and images by a given point, or developer sources stock imagery and drafts copy for client sign-off. Either is fine. Not deciding is the problem.

Approval matters just as much as authorship. Who signs off the homepage before it goes live? Is it you, or does it need a trustee, a committee or a board? If you're running a club or charity, build that approval chain into the timeline now, not after the developer has built three pages nobody with authority has actually seen.

Hosting, domain control and who holds the keys

Your domain name and hosting account are the keys to your own front door. A brief should state clearly who registers the domain, whose name it sits under, and who has the login details for hosting. If a developer registers your domain in their own account and the relationship later sours, you can find yourself locked out of your own website and email. Insist the domain is registered in your organisation's name, and insist you're given full access credentials, not just promised them "if you ever need them".

The same goes for hosting. Ask where the site will be hosted, who pays the hosting bill, and what happens to the site and its data if you decide to move to a different developer in future. A good developer won't flinch at these questions. If they do, that tells you something useful before you've signed anything.

Timeline expectations and who owns the finished code

Timelines slip for two reasons: scope that was never properly fixed, and content that arrives late. A brief should set out the key milestones, who is on the hook for each one, and what happens to the schedule if content is delayed on your end. Agree this upfront and you avoid the awkward conversation later about whose fault the delay actually was.

Then there's the question almost nobody asks until it matters: who owns the code once the site is finished? Under UK law, this isn't automatically you. Section 11(1) of the Copyright, Designs and Patents Act 1988 makes the author, the developer who actually wrote the code, the first owner of copyright in it, not the client who commissioned it. There's an exception in section 11(2) for employees creating work in the course of their employment, where the employer owns it instead. But freelance developers are not employees of yours, so that exception doesn't apply to work they produce for you, as the same source explains. In practice, this means ownership of the finished site has to be assigned to you explicitly, usually in the contract, rather than assumed. If your brief or contract is silent on this point, you may be paying for a website you don't actually own outright. Ask the question directly and get the answer in writing before work starts, not after the invoice.

What to do now

Before you approach any developer, write down your scope, who's handling content, who controls the domain and hosting, your expected timeline, and a clear statement that you want ownership of the finished code assigned to you. That single page will save you more money than any amount of haggling over the final invoice.

If you'd rather talk it through with someone who'll ask the awkward questions for you, get in touch via our contact page to request a quote, or have a look at how we approach projects on our web development page first.

Sources

• Google / web.dev, Learn web development | web.dev
• Government Digital Service (GDS), How we're helping public sector websites meet accessibility requirements, 24 September 2018
• Government Digital Service (GDS), Accessibility update: sample accessibility statement, monitoring and enforcement, 21 May 2019
• Level Access, A Complete Guide to UK Digital Accessibility Requirements
• Bracton, IP ownership: who owns what you create, and how to make it clear
• ask.legal, SME IP protection in the UK: Who owns the copyright when I hire a freelancer to design my company logo?, 7 November 2025
• Nordstone, Who Owns Your App's Code? UK IP Guide for Founders (2026), 1 July 2026
• LegalDocuments.co.uk, Copyright in the UK: A Practical Guide for Creators