How to write a website brief that gets you honest quotes

A large share of the enquiries we receive are one sentence long: "We need a corporate website — can you quote us a price?" It is impossible to answer that honestly. It is the "I want a car, how much?" of web development. The outcome is predictable: one vendor quotes an inflated number, another quotes low to win the job and bills the difference later as "extras", and you end up trying to compare proposals that describe entirely different projects. Knowing how to write a website brief prevents exactly this chaos. And contrary to what most people assume, writing one takes an afternoon, not a week.

Let's start with a confession: your brief does not need to be perfect. A good studio fills the gaps with questions — that is what the first meeting is for. But with no brief at all, that meeting turns from a conversation into an archaeology dig, and every quote you receive rests on a different set of assumptions. The brief protects you: it is the only way to compare apples to apples.

Why does a website brief make such a difference?

Three concrete reasons:

1. Proposals become comparable. One vendor hears "corporate website" and pictures a five-page brochure; another pictures a thirty-page multilingual portal. Proposals written against the same brief price the same job — and whatever difference remains is the real difference: approach, quality, experience.
2. The project moves faster. The number one reason projects drag is not technical difficulty; it is ideas changing mid-flight. A scope written down at the start makes the "while we're at it, let's also add..." spiral visible and negotiable. One of the preconditions for our ability to ship an MVP in 4–6 weeks is starting with a clear scope.
3. It filters out bad matches early. A well-written brief lets some vendors say "this isn't for us" — which is not a loss but a gift, compared with losing three months to the wrong supplier. We reply to every enquiry within 48 hours with a clear yes or no; more often than not, what makes a fast, confident "no" possible is a good brief.

What goes into a good brief: seven sections

1. The business: what do you sell, and to whom?

Two paragraphs are enough. What you do, who your customer is, what separates you from competitors. This feels trivially obvious to you — remember that the reader knows none of it. Bonus: you will later measure how well each vendor understood your industry by the quality of the questions they ask about these two paragraphs.

2. The site's job: one sentence

This is the heart of the brief, and the part most often waved away. "It should represent us well" is not a job. A job sounds like: "Collect distributor applications." "Present our catalogue to export-market buyers." "Increase qualified applications to our job openings." Pick one primary job. A site that tries to do everything does nothing well — and every later decision, from design to copy, will be made against this one sentence.

3. Page and content inventory

Roughly which pages will exist: home, services (how many?), case studies, blog, contact... Nobody expects a perfect sitemap; a sense of size is enough. But do answer these two questions explicitly:

• Where will the content come from? Are texts and images ready, or do they need to be produced? The single most classic cause of delay in web projects is not code — it is content that never arrives. If you write "copy comes from us", also write who will write it and by when.
• How many languages? Multilingual support is among the most painful features to bolt on later; knowing it upfront changes the architecture.

4. Functionality: what must it do?

Forms, newsletter, search, member accounts, payments? Integrations with existing systems — CRM, ERP, accounting, booking? There is a serious cost and architecture gap between "our products should appear on the site" and "products should sync automatically from our ERP". Where you are unsure, leave the question open: "Our product data lives in system X and we don't know how it would talk to a website" is an excellent brief sentence. Writing down what you don't know is not weakness; it is precision.

5. Sites you like — and why

Give three to five links; competitors or completely unrelated industries, both fine. The critical part is the why: "the restraint of this one", "the product filtering on that one", "this one's typography". A list of examples without reasons actively misleads — you liked the overall mood, the designer copies the menu structure. Listing sites you dislike is at least as useful.

6. Budget range: yes, write it down

The most resisted item. The fear — "if we reveal the budget, they'll inflate the quote to match" — is understandable, but the maths runs the other way: quotes against a budget-less brief scatter across such a wide range that comparison becomes impossible. A budget range is not a target price; it is a filter. It prevents a 200-thousand expectation and a 2-million scope from wasting each other's time. Can't give a number? Give a range. Can't give a range? At least give the order of magnitude. And if a vendor hears your budget and shapes the scope to fit it — that is not the trap; that is exactly what you want. The trap is the same scope getting pricier, and comparable proposals expose that on their own.

7. Timeline and decision process

When must it be live, and is there a real reason for that date — a trade fair, a launch, a season? And the critical question: who decides? Will a five-person committee approve the design, or one person? Saying this upfront sets the project's rhythm; a committee process where every revision round takes a week and a single-approver process that turns around in two days do not fit the same calendar.

What to leave out of the brief

An equally important question. Three things weaken a brief:

• Prescribed solutions. Technology decisions — "build it in WordPress", "use React" — belong to the vendor's expertise, not the brief, unless there is a genuine organisational constraint. Describe the problem; let defending the technology choice be the vendor's job. A brief that dictates the stack doesn't find the best solution — it finds the most obedient supplier.
• A pile of vague adjectives. "Modern, dynamic, user-friendly, striking" carry zero information; every vendor says yes to all of them. Replace each adjective with an example (see section 5).
• False certainty. Writing uncertain scope as if it were settled comes back to you later as change costs. Marking the unclear parts as "unclear" is one of the most professional moves a brief can make.

Is one page really enough?

For most projects, yes. A few sentences under each of the seven headings — one page, two at most. Forty-page requirement documents belong to large enterprise tenders; on a mid-sized web project they produce more bureaucracy than clarity. The brief's purpose is not to be a legal document but to start the right conversation — the contract and the detailed scope get written together, later.

If you have an honest one-page brief — even with only five of the seven sections filled in — send it to us via vucod.com. We reply to every enquiry within 48 hours with a clear answer either way, and a good brief makes that answer both faster and more accurate.