To brief a web developer so the quote is accurate, write down what the site must achieve, what exists now and how they can access it, every page and feature you need, the systems it must connect to, who supplies the content, your deadline and budget range, examples you like, and who makes the final decision. A one-page brief with those eight points gets you quotes you can compare. A two-line message gets you guesses.
The developer’s side matters as much: a good reply sends back a written scope, the assumptions behind it, milestones and a clear list of what is not included.
Why vague briefs produce bad quotes
A developer quoting from “we need a new website, something modern” has two options: quote high to cover unknowns, or quote low and raise the price once the real requirements appear. Neither helps you. Three developers given the same vague brief will each imagine a different project, so their quotes cannot be compared.
When I read a brief, the questions I ask first are about integrations, content and who signs off, because those are where scope usually grows after work has started.
What to include in the brief
1. Goals
Say what the site or change is for, in business terms: more enquiries, online sales, fewer support emails, a faster checkout, moving off an old platform. Add how you will judge success and how you measure it today (for example, form submissions in your analytics). Without a goal, a developer cannot suggest a simpler way to get there.
2. Current site and access
- The URL and platform (WordPress, WooCommerce, Shopify, custom PHP, something else).
- Who hosts it, who controls the domain and DNS, and whether you have the logins.
- What works and what does not. Be specific: “the quote form emails go to spam” is useful, “the site is slow” is a starting point.
- Whether old URLs must be kept or redirected, if search traffic matters to you.
Do not send passwords in the first email. Say what access you can provide once the work is agreed, and create a separate account for the developer at that point.
3. Pages and features list
List every page or template and every feature, even the obvious ones. A table helps:
- Page or feature: what it is (home page, service pages, blog, product pages, booking form, member area).
- Quantity: how many service pages, how many products, how many languages.
- Must have or nice to have: so the developer can price a core version and options.
“A blog” can mean five posts or a thousand imported from another system. Numbers change the quote.
4. Integrations
Name every system the site must talk to: CRM, email marketing, payment gateway, booking tool, stock or ERP system, accounting software, shipping, analytics. For each, say whether it already exists, which plan or account you use, and what data should move in which direction. Integrations are the most common reason a quote turns out to be wrong.
5. Content ownership
Who writes the text, who supplies photos, who moves old content across? If the developer is expected to migrate content, say how much. Also say who will own the finished code, design files and accounts, and that the domain and hosting should stay in your name.
6. Deadline and budget range
Give a real deadline and why it matters: a launch event, a sale, a contract ending with an old supplier. Then give a budget range. It is tempting to hold this back to see what comes in, but a range lets the developer propose what fits rather than the most complete version. It is the single biggest help you can give to getting a realistic proposal.
7. Examples you like, and why
Two or three links to sites you like, with one line on each: “clear pricing table”, “the way the menu works on mobile”, “simple checkout”. “We like this site” without a reason does not tell the developer which part you mean.
8. Who decides
Name the person who approves designs, answers questions and signs off each stage. If a board, a partner or a marketing team also has a say, list them. Unclear sign-off adds rounds of changes that nobody priced.
What a developer should send back
A useful proposal is more than a number. Expect:
- Scope: the pages, features and integrations they will deliver, in their own words. If it does not match your brief, you have found a misunderstanding early.
- Assumptions: for example, “client supplies all copy”, “uses an existing theme”, “up to two rounds of design changes”, “payment gateway account already active”.
- Milestones: stages with what you will see at each one (staging site, first templates, content loaded, launch), and what they need from you before each stage starts.
- Out of scope: a written list of what is not included, such as copywriting, ongoing maintenance, paid plugins or apps, hosting costs, and work after launch.
- Questions: a good developer asks some. A proposal with no questions on a complex brief is a warning sign.
For examples of how scope looks on projects with several integrations, see Sapphire Balconies, headless WordPress with Contact Form 7 and HubSpot and The Healing Wiz website rebuild in Next.js.
Red flags on both sides
From the developer
- A firm quote within minutes on a brief with several integrations, with no questions asked.
- No written scope or out-of-scope list, only a total.
- Asking for your main admin or hosting password before anything is agreed, instead of a separate account.
- Plans to register the domain or hosting in their own name.
- No staging site; changes go straight to the live site.
From the client
- “Just like Amazon” or “like this site” with no detail on which parts.
- A deadline with no flexibility and content that does not exist yet.
- No named decision-maker, or several people giving conflicting feedback.
- Refusing to share any budget range while expecting a detailed proposal.
- Expecting work outside the agreed scope to be included because it seems small.
If you spot one of these in the first week, raise it then. It is cheaper to fix a brief than a half-built site.
Timing your brief around the holidays
If you want work to start in the new year, send briefs before the holiday period, because replies slow down around 25 and 26 December.
- Now to late November: write the brief, collect access details, decide who signs off. Store owners will be busy around Black Friday (27 November) and Cyber Monday (30 November), so plan any live-site work for after it.
- Early December: send the brief, compare proposals, ask follow-up questions.
- Mid to late December: agree scope and milestones in writing.
- January 2027: start the project. If you run a WordPress site still on PHP 8.2, which loses security support on 31 December 2026, add the PHP upgrade to the brief.
Frequently asked questions
How long should a brief for a web developer be?
One to three pages is enough for most projects. Cover the eight points above; length matters less than numbers and specifics.
Should I tell a developer my budget?
Give a range. It lets the developer propose what fits, and it filters out mismatches before anyone spends time on a detailed proposal.
What if I do not know which features I need?
Describe the goal and the problem, and ask for a short paid discovery or consultation stage that ends with a written scope. That scope then becomes the brief.
Should I send the same brief to several developers?
Yes. The same written brief makes the proposals comparable. Compare the scope and assumptions, not only the total.
If you are deciding who to work with, you can read how I take on projects as a freelance web developer working with clients remotely. When your brief is ready, send it to me and I will reply with questions or a written scope.