How to write a website brief

Most website projects that go badly went badly before anyone wrote a line of code. The quote was based on a paragraph, the paragraph left something out, and the argument three months later is about which of you was supposed to have assumed it.

A brief is not a formal document and it does not need a template with a logo on it. It is the answers to seven questions, written down. An hour spent on it will save you weeks, and it will get you comparable quotes instead of numbers you cannot compare.

1. What is the site for

Not “we need a website”. One sentence describing what a successful visit looks like.

• Someone searching for a physiotherapist in Karachi finds us, trusts us, and books an appointment.
• An existing client finds the reorder form and places an order without calling.
• An investor reads the case studies and requests a meeting.

This is the sentence every later decision gets tested against, and it is astonishing how many projects do not have one. If you cannot write it, that is not a failure of the brief — it is the actual first task, and no developer can do it for you.

2. Who is it for

One or two real audiences, described as people rather than demographics. “Facilities managers at hospitals who have been told to cut costs” is useful. “Ages 25–54, urban” is not.

For each, say what they need to see before they act. A facilities manager needs compliance details and a reference; a bride needs photographs and a price range. Those are different websites.

3. What is on it

A page list. Not a sitemap diagram — a list.

The important part is not the count, it is which pages are different from each other. Ten service pages sharing one layout is roughly one page of work. Ten pages that each need their own structure is ten. Developers price by unique layouts, and page count alone tells them nothing.

Mark each page as new, rewritten or moved as-is, which answers the next question before it is asked.

4. Who writes the words

The single most common reason projects stall, and it is always the same shape: the quote quietly assumed you would supply finished copy, and you assumed the developer would write it. Six weeks pass with the build finished and nothing to put in it.

Decide explicitly, per page if it varies:

• You write it — cheapest, and it will be late. Say when.
• They write it — costs real money, and needs interview time from you.
• They rewrite what exists — the usual middle, and it is genuinely cheaper.

The same question applies to photographs. Stock images are free-ish and look it; a photographer is a real line item; existing photos may not be usable at web sizes. Say which it is.

5. What it must connect to

List every system by name. This is where the hours actually go, and it is what separates a five-figure quote from a four-figure one.

Payments, booking or calendar systems, a CRM, WhatsApp, an accounting package, a stock system, an email tool, a courier’s tracking. For each, say whether it must be live and two-way or whether a form emailing someone is genuinely enough — because those are very different jobs and clients often ask for the first when the second is what they need.

6. What already exists

The state of the current site decides a surprising share of the price.

• Is there a site now? Its URLs need redirecting, or you throw away everything it earned in search.
• Where is the domain registered, and do you have the login? If the answer is “the last developer has it”, start solving that today. It is the single most common thing that delays a launch.
• Who has the hosting, the analytics, the Business Profile? Same question.
• What must not change? A phone number people have on printed material, a URL in a running ad campaign, an email address on a thousand business cards.

7. When, and roughly how much

The deadline, and what it is tied to. “End of the quarter” is a wish. “Before the trade fair on the 12th” is a constraint, and it changes what a sensible plan looks like.

A budget range. This is the one people resist, and withholding it costs you. Without a range you get quotes across an order of magnitude and no way to judge them; with one you get proposals that fit and you can compare what each includes.

You are not weakening your position. Anyone who inflates a quote to consume a stated budget has told you something useful about themselves, early and cheaply.

What to ask for back

A brief is half the conversation. What comes back should include:

• A fixed price for a defined scope, or a clear day rate with an estimate and the assumptions behind it.
• What is explicitly not included. More useful than the inclusions list, and more revealing.
• How many revision rounds, and what happens after them. “Unlimited revisions” is an unpriced risk that gets priced somewhere you cannot see.
• Who owns the code, the domain, the hosting and the analytics at the end. The answer should be you, in writing, from day one.
• What happens after launch — how long support lasts, what it covers, what it costs afterwards.

If two quotes differ by a factor of three, the answers to those five questions will usually explain the whole gap.

The one-hour version

If you write nothing else, write these, in an email:

1. What a successful visit looks like, in one sentence.
2. Who is visiting, and what they need to see before acting.
3. The page list, marked new / rewritten / as-is.
4. Who writes the words, and who supplies photographs.
5. Every system it must connect to, by name.
6. What exists now, and who holds the accounts.
7. The deadline and a budget range.

That is a better brief than most projects start with, and it is genuinely an hour. It also does something a longer document does not: it makes two quotes comparable, because both are answering the same questions.

---

Send us that and you will get a fixed number and a straight answer on what it takes — including, when it is true, that what you are describing does not need us. Start there. If the branding is part of it, the logo brief is the companion piece.