How to Write a Website Brief That Gets You Accurate Quotes

Ask five developers to quote the same project and you will get numbers that differ by a factor of five. Most owners conclude that the cheap ones are cowboys or the expensive ones are greedy, and sometimes that is true – but far more often the spread has a simpler cause: the project was never described clearly enough to price. A good website brief fixes that. It is one page. It takes an hour to write. And it changes what comes back to you: instead of five guesses wrapped in safety margins, you get comparable, accurate quotes from people who understood what you want – and a much smaller chance of a scope fight three weeks into the build.

I read hundreds of briefs a year as a freelance WordPress developer working with small businesses and agencies in Germany, the UK, the US and Australia, and I can usually predict how a project will go from the first email. This guide is the developer’s-eye view: why vague briefs produce padded quotes, the ten sections a useful brief contains (including the one everybody omits – budget – and why stating it helps you, not the developer), real examples of vague lines rewritten as specific ones, what you should deliberately leave out, how developers actually read what you send, a copy-paste template, and the red flags to watch for in the replies you get back.

Table of contents

• Why quotes for the same project vary 5x
• What a good website brief is – and is not
• The ten sections of a brief that gets accurate quotes
• Why stating your budget helps you, not the developer
• Vague vs specific: the same project, two briefs
• What NOT to put in a website brief
• How developers actually read your brief
• The copy-paste website brief template
• Red flags in the replies you get back
• After you send it: comparing the quotes
• Frequently asked questions

Why quotes for the same project vary 5x

When a developer reads “we need a website for our consulting firm, around 6 pages, modern design, contact form”, they are not reading a specification – they are reading a probability cloud. Six pages could mean six short pages from finished text, or six pages the developer must structure, populate and extend with a blog, a careers section and a newsletter signup that “we assumed was included”. “Modern design” could mean a clean template-style layout or a bespoke design with animations. The contact form could be one form or a multi-step quote calculator that feeds a CRM.

Every unknown gets priced one of three ways. Careful developers add a risk margin – they quote high enough that the worst reasonable interpretation still leaves them whole. Optimistic developers quote the best-case interpretation and make the difference back later through change requests, which is where scope fights are born. And volume shops quote a low anchor number knowing that “that was not included” is a sentence they will use often. Send a vague brief to five developers and you have effectively asked five people to price five different projects – the 5x spread is not dishonesty, it is uncertainty pricing.

• Vague brief, careful developer: high quote with padding you cannot see, for risks you could have removed.
• Vague brief, optimistic developer: attractive quote, followed by paid “extras” for things you thought were obvious.
• Specific brief, any honest developer: a number that reflects the actual work, and quotes you can compare line by line.

The economics are worth stating plainly: uncertainty always costs the client, never the developer. A one-page brief is the cheapest project insurance you will ever write.

What a good website brief is – and is not

A website brief is a one-page description of what the site must achieve, what it contains, what it connects to and what constraints apply. It is written in plain language by someone who knows the business – no technical vocabulary required. Its job is to let a professional price and plan the work without guessing.

It is not a specification. You are not expected to know page counts to the pixel, name plugins, or draw wireframes. It is not a wish list of everything the site might ever do – a brief describes the version you are buying now, with one line about where it might go later. And it is not a legal document; the developer’s quote and scope statement will do that job. Think of the brief the way you would think of describing symptoms to a doctor: your job is to describe what you observe and what you want to be true; diagnosis and treatment are the professional’s job.

Length matters more than people expect, in both directions. Three sentences force the developer to guess, and you pay for the guessing. Fifteen pages get skimmed – genuinely; nobody prices a novel – and the important constraint buried on page 11 gets missed. One page, structured under clear headings, is the format that gets read completely and priced accurately. If a section deserves depth (a features list for a store, for example), attach it separately and reference it in one line.

The ten sections of a brief that gets accurate quotes

Ten short answers – most of them one to three lines. Write them in order; the sequence itself tells the story of the project.

1. Goals: what the site must achieve

Not “have a website” – the business outcome. “Generate enquiries from facility managers in the Frankfurt region”, “take bookings so we stop handling them by phone”, “make us look credible enough to win contracts against bigger competitors”. One or two sentences. This is the most important section in the brief, because every judgement call the developer makes during the build – and there are hundreds – gets made against it. A site whose goal is enquiries gets a different homepage, different forms and different calls to action than a site whose goal is credibility.

2. Audience: who the site is for

Who visits, what they already know, what device they are likely on, and what language or markets matter. “Homeowners aged 40+, mostly on phones, found us via Google” leads to different decisions than “procurement teams comparing three suppliers on desktop”. If you serve more than one audience, say which one pays the bills – the site should be optimised for them.

3. Pages: what the site contains

List the pages by name: home, about, four service pages (name them), projects, contact, legal pages. A simple list is enough – you do not need a sitemap diagram. If you are not sure whether something is a page or a section, write it down anyway and let the developer propose the structure. Ranges are fine (“6-8 pages”) as long as you name what you are sure about.

4. Features: what the site must do

Everything beyond displaying text and images: forms (how many, what fields matter, where submissions go), a blog, a booking flow, search, a members’ area, multiple languages, a shop. Describe features as outcomes, not mechanisms: “customers pick a time slot and we get an email plus a calendar entry” is a perfect feature description. Flag anything that involves money, logins or personal data – those carry the most hidden work.

5. Integrations: what the site connects to

The section most often omitted and most often expensive. CRM (which one?), newsletter tool, accounting or ERP software, payment providers, booking or job-board systems, Google services. “Form entries must land in HubSpot” is one line in a brief and, unmentioned, a four-figure surprise after launch. If you do not know whether a connection is needed, name the tool you use and let the developer ask.

6. Content status: what exists and who writes the rest

Do texts, photos and translations exist, or must they be created – and by whom? Content is the number one cause of website delays, ahead of anything technical, so developers price and schedule around it. “Text for all pages is written, photos come from a shoot in week two” is a green light. “We will write it as we go” honestly stated lets the developer plan around it (and perhaps quote copywriting help) instead of discovering it in week three of an eight-week timeline.

7. Design references: two or three sites, with WHY

Links alone are useless – I have received “we like apple.com” from a company selling industrial fasteners. The why is the useful part: “we like this site’s calm colours and big photography, but our version needs to feel more technical” gives a designer or developer real direction. Two or three references with one sentence each beats a mood board. Mention your existing brand assets too: logo files, brand colours, a style guide if one exists.

8. Hosting: where the site will live

Do you have hosting and a domain already (name the provider), or do you need a recommendation? Who has the access credentials? If there is an existing site, does anything on it need to survive – email accounts are the classic casualty. Two lines here prevent the most stressful launch-day surprises; the ones I keep having to fix appear in my website launch checklist.

9. Deadline: when, and why

A date plus the reason for it. “Live in eight weeks because we exhibit at a trade fair” is a real constraint the developer can plan around – perhaps by phasing the build so the essential pages go live first. “As soon as possible” communicates nothing except impatience; every project wants to be done soon. If there is no hard date, say so – honest flexibility is also useful information, and it sometimes earns you a better price for filling a quiet slot.

10. Budget: the range you have in mind

The section everyone omits, and the one that changes the reply most. A range is enough: “EUR 3,000-5,000 for the build, plus ongoing costs”. The next section explains why this helps you rather than weakens you – it is the most misunderstood line in the entire brief.

Two closing habits: keep the whole thing to one page, and end it with an explicit invitation to ask questions. The brief is the start of a conversation, not a sealed bid document.

Why stating your budget helps you, not the developer

The fear is understandable: “if I say EUR 5,000, they will quote EUR 5,000 even if the work is worth EUR 3,000”. With a dishonest developer, that can happen – but a dishonest developer will overcharge you with or without a stated budget, and the red flags section below is how you catch them. With honest professionals, hiding the budget costs you three things.

• You lose the fit conversation. Almost any website wish list can be built at three different depths: a solid version, a comfortable version and a deluxe version. If I know you have EUR 4,000, I will tell you which of your ten features fit inside it, which one to postpone, and where the money works hardest. If I do not, I quote the version I guess you mean – and my guess may be a EUR 12,000 build you never intended, or a EUR 2,000 build that undersells your project.
• You waste rounds of the slow no. Without a budget, the mismatch surfaces only after each side has spent hours – you brief, they scope, they quote, you decline, repeat with the next candidate. A stated range filters instantly: developers for whom it cannot work say so in the first reply, politely, and everyone saves a week.
• You cannot judge trade-offs. When quotes come back at different numbers, the budget context is what lets a good developer explain what you gain or lose at each level. “Within your range I would do X and skip Y” is the most useful sentence a quote can contain, and it is only possible when the range exists.

If you genuinely do not know what is realistic, say that instead – “we have not set a budget; please quote what this scope honestly requires” – and do some calibration reading first. I published detailed number ranges in how much a custom WordPress website costs; an hour with real figures turns “no idea” into a defensible range.

Vague vs specific: the same project, two briefs

Specificity is not about writing more – the specific version of most brief lines is barely longer than the vague one. It is about replacing adjectives with facts. Here are the rewrites I find myself wishing for most often:

• Pages. Vague: “a few pages, nothing fancy”. Specific: “home, four service pages (repair, installation, maintenance, emergency call-out), about, contact, imprint and privacy”. The vague version could be four pages or fourteen; the specific one is priceable in a minute.
• Design. Vague: “modern and clean, it should pop”. Specific: “we like example-site A for its calm colours and big photos, and example-site B’s project gallery; ours should feel more technical than either”. Adjectives mean different things to every reader; references with reasons mean the same thing to everyone.
• Features. Vague: “a contact form and stuff like that”. Specific: “a quote-request form with a file upload for plans, sending to two email addresses”. The word “stuff” is where budgets go to die.
• Future plans. Vague: “we might sell things later”. Specific: “no shop at launch; if it happens it would be around 20 products in a year or two”. The first version tempts the developer to price shop-readiness now; the second lets them build sensible foundations without gold-plating.
• Deadline. Vague: “as soon as possible”. Specific: “live in eight weeks – we exhibit at a trade fair and the site is on the printed material”. One is a mood; the other is a plannable constraint.
• Budget. Vague: “depends what it costs”. Specific: “EUR 3,000-5,000 for the build”. You know the argument by now.

A useful self-test before sending: read each line and ask whether two different people could honestly picture two different projects from it. If yes, add the fact that closes the gap. You will rarely need more than one sentence.

What NOT to put in a website brief

Over-specifying is the quieter failure mode. When a brief dictates implementation – “build it with Elementor, use plugin X for the slider, host it on provider Y” – three bad things happen: you take responsibility for technical decisions you hired an expert to make, you filter out developers who know a better way but assume you will not budge, and you sometimes force a worse, more expensive build than the one a professional would have chosen.

• Leave out named plugins and page builders – describe the outcome (“the team must be able to edit text and swap images without breaking the layout”) and let the developer propose the tool. If you have a hard requirement from experience (“our last builder site was unmaintainable; we want a custom theme”), state it as a requirement with its reason – that is a constraint, not an implementation detail.
• Leave out technical SEO instructions copied from a blog post (“we need schema markup and 90+ PageSpeed”). Say the goal instead: “being found for X in region Y matters to us”. A serious developer builds the technical foundations anyway, and the goal version lets them tell you what actually moves the needle.
• Leave out pixel-level design directives unless you have a designer and a finished design file – in which case say so, because “build exactly this Figma file” is a different (and very priceable) project than “design and build”.
• Leave out the solution when you mean the problem. “We need a chatbot” is a solution; “customers ask the same ten questions by phone” is the problem – and it might be better solved with a well-structured FAQ page at a tenth of the price. Brief the problem; buy the solution after you have heard options.

The dividing line is simple: constraints and outcomes belong in the brief; mechanisms belong in the reply. You are allowed to have opinions about mechanisms – raise them in the conversation the brief starts, where a professional can agree or push back with reasons.

How developers actually read your brief

Knowing how the other side reads helps you write. When a brief lands in my inbox, the first pass takes about two minutes and answers three questions: is this project real (a goal, a decision-maker, some evidence of thought), is it in my lane, and can it work commercially (budget or a scope that implies one). Briefs that fail the two-minute pass do not get careful quotes – they get either a polite decline or, from less scrupulous shops, exactly the padded template quote this article is trying to save you from.

The second pass is where your specificity pays. I go line by line building the work list: pages become templates, features become effort estimates, integrations get checked against APIs I know, content status shapes the schedule, the deadline gets sanity-checked against my calendar. Everything clear goes on the list at its real cost. Everything unclear generates either a question or a risk margin – and which one it generates depends on the overall impression of the brief. A tidy one-pager earns questions, because it signals a client worth the effort; a rambling wish list earns margins, because the brief predicts how the project will feel. Fair or not, your brief is a sample of what working with you is like, and every developer prices that in.

The third thing a good developer reads is what you did not write. No mention of content? I will ask, because it is the number one schedule killer. No mention of an old site? I will ask what happens to it, because redirects and email are launch-day landmines. The quality of the questions that come back is one of the best selection signals you get – which is exactly the subject of how to choose a WordPress developer or agency.

The copy-paste website brief template

Here is the whole thing as a table you can copy into an email or document. Replace the examples, delete what does not apply, keep it to a page.

Send it as plain text or a one-page PDF – not as a form the developer must fill in, and not inside a procurement portal if you can avoid it. End with the invitation: “Happy to answer questions before you quote.” The developers worth hiring will take you up on it.

Red flags in the replies you get back

A good brief does something beyond producing accurate quotes: it makes the replies comparable, and it makes bad developers visible. Watch for these patterns in what comes back:

• A quote with no questions. You described integrations, content gaps and a deadline – and someone priced it within two hours without asking anything? They either did not read it or plan to renegotiate later. Real projects generate at least one clarifying question; my own rule is a reply within 24 hours, but a considered one.
• A number with no scope. “EUR 2,400 for the whole thing” with no list of what “the whole thing” contains is not a quote, it is bait. An honest quote restates your requirements in the developer’s own words – that restatement is your proof they understood the project.
• Everything is “included”. If the shop, the second language, the CRM connection and the copywriting are all mysteriously inside the lowest bid, something is wrong – usually the definition of “included”.
• Pressure tactics. “This price is valid for 48 hours” on a four-figure project is a sales trick, not a schedule reality. Legitimate availability constraints (“my next free slot is in five weeks”) sound different from manufactured urgency.
• Answers to a different brief. A template reply that praises your “e-commerce vision” when you asked for a brochure site tells you your one page was never read. Imagine what reading their emails during the project will be like.
• No pushback anywhere. Strange but true: if your brief contained a questionable idea (they usually do – mine would too) and nobody pushed back on anything, nobody was thinking. The developer who says “I would not build the animation you described, and here is why” is showing you the judgement you are actually paying for.

The pleasant surprise most owners report: with a specific brief, the good replies get noticeably better. Professionals respond to a clear brief with their best work, because it signals a project – and a client – worth having.

After you send it: comparing the quotes

Give it a few working days, then line the replies up. Because everyone priced the same document, differences now mean something. Compare scope line by line against your ten sections: does each quote cover every page, feature and integration you listed, and does it say who provides content? Separate build price from running costs (hosting, licences, maintenance) – the cheapest build is sometimes the most expensive site over three years. Note what each developer flagged, asked or challenged; that is a preview of their judgement. And weigh the communication itself: response time, clarity, whether questions were about understanding your business or just narrowing their liability.

Expect the spread to shrink from 5x to something like 1.5-2x – the remaining difference is real (seniority, country, custom code versus assembly, what “done” means) and now you can interrogate it: ask the expensive quote what you get for the difference, and ask the cheap one what is not included. Both answers are informative. Then pick partly on price and mostly on evidence: portfolio, scores, references, and the quality of the conversation your brief started. A vague brief buys you a lottery; a specific one buys you a decision.

Want a quote against your brief?

Send me your website brief – or your honest attempt at one – and I will reply within 24 hours with questions worth asking and a fixed quote, whether it is a new build, a rebuild or something in between. See my custom WordPress development service and portfolio, then send the brief through the contact page. If it is missing half the sections above, that is fine – the questions I send back will fill them in.

Frequently asked questions

What is a website brief?

A website brief is a one-page document describing what a website must achieve, its audience, pages, features, integrations, content status, design references, hosting, deadline and budget range. It lets developers quote accurately instead of guessing.

How long should a website brief be?

One page. Shorter forces the developer to guess and pads your quote; longer gets skimmed and the important constraints get missed. Attach detailed lists separately if a section genuinely needs depth.

Should I include my budget in a website brief?

Yes, as a range. It lets honest developers fit the scope to your money, filters out mismatches before anyone wastes a week, and enables the useful “within your range I would do X and skip Y” conversation. Dishonest developers overcharge with or without it.

Do I need technical knowledge to write a website brief?

No. Describe outcomes in plain language – “customers book a time slot and we get an email” – and leave tools, plugins and technical decisions to the professional you are hiring.

What is the most common mistake in website briefs?

Adjectives instead of facts: “modern, clean, a few pages, ASAP”. Every vague line becomes either a hidden risk margin in your quote or a paid change request later. The second most common: omitting integrations like CRM or newsletter tools.

How many developers should I send my brief to?

Three to five. Fewer gives you no comparison; more creates evaluation work without better information. Because they all price the same document, their replies become genuinely comparable.

What if I cannot answer all ten sections?

Send it anyway with the gaps marked honestly – “content not written yet, no budget set”. Named unknowns are plannable; hidden ones are expensive. A good developer’s first reply will help you close them.