A website brief is not paperwork for the developer - it is the one document that lets a quote be calculated instead of guessed. Most checklists you find online look much the same: twenty questions, half of them lifted from a marketing survey, and not a word about what happens to the answers afterwards. That last part is the whole game. One answer can move the number by thousands, another changes nothing at all, and a third decides whether the project starts next week or in six.
What follows is a brief in a form you can select, paste into an email and fill in within fifteen minutes. Next to each point I say plainly what that answer moves in the price or the schedule, so you know where to put the effort and what you can safely leave blank. I have written separately about what to send in the quote request itself; this piece is about the document that stays with you for the whole project.
A website brief - ten points to copy
It does not have to look good. Bullet points, one or two sentences each, written between meetings is fine.
1. What the company does and who it sells to. Two sentences. What it moves: the layout and the number of selling screens. A manufacturer selling to wholesalers and a clinic taking appointments are two different sites at the same page count.
2. What the site is for - one goal, not five. Email enquiries, phone calls, online sales, credibility in tenders. What it moves: very little in the price, a great deal in whether the site works. This is the only question nobody can answer for you.
3. The address of your current site, if there is one. Even if you are embarrassed by it. What it moves: half a day of my work either way. An old site often yields text, photos and page addresses worth keeping - or it shows immediately that nothing is salvageable and everything gets built from scratch.
4. The list of pages, or what has to be on the site. It does not have to be complete. What it moves: more than any other point. Every page is design, content and build, so the gap between six screens and twenty-six is a gap in order of magnitude.
5. Who writes the copy. You, me, or nobody has thought about it yet. What it moves: both price and date. Missing copy is the most common reason a technically finished site sits for a month before launch.
6. Photos and logo - what you already have. Job photos, team photos, a vector logo file, brand guidelines. What it moves: the price, because the alternative is stock imagery or a photo shoot, and both are separate line items.
7. What the site has to do beyond showing content. A form, a calculator, appointment booking, a client login area, online sales. What it moves: the number, in steps. This is the border between a website and a system, and it runs exactly here.
8. What it has to connect to. Warehouse software, accounting, a CRM, a calendar, a supplier feed. What it moves: the schedule more than the price. An integration with someone else’s system depends on their documentation, which I do not control - which is why it is honest to carve it out as its own stage.
9. Languages and accessibility. How many languages, who translates, and whether the company falls under digital accessibility rules. What it moves: a second language is effectively a second site in content terms, and an accessibility requirement changes how the site is designed, not what gets patched at the end.
10. Timeline, a rough budget, and who decides. What it moves: everything, only not in the direction you are afraid of. A budget does not raise the price - it lets me shape a scope that fits inside it, instead of sending an offer twice as high that you bin unread. And one decision-maker on your side shortens a project more than any efficiency on mine.
What does not belong in the brief
Plenty of people sit on a brief because they feel they still do not know something. Usually it is something they should not be deciding.
You do not have to pick the technology, the content management system or the hosting - that is the developer’s call, and they should be able to justify it. You do not need a domain bought or a template chosen. You do not need the jargon either: saying that you want people to call after they have looked at your past work carries more information than any sentence about conversion funnels. If a brief names a specific plugin or theme somebody recommended to you, I treat it as a hint rather than a requirement - sometimes it is spot on, sometimes it blocks a better answer. On judging the developer in the first place, I put the criteria together in who can build my website.
Copy, assets and integrations - where most projects stall
In my experience the technical work is rarely the bottleneck. Projects stall on three things, and all three are visible at brief stage.
The first is copy. The client says they will write it themselves because nobody knows the business better - which is true, except that writing twenty service descriptions in the evenings takes time. If the brief says outright that the copy does not exist and will not exist, I put it in scope and the date holds. If it says the copy is coming, we agree on a date and that date becomes part of the schedule.
The second is photography. A construction company usually has hundreds of site photos on its crew’s phones and none at a resolution fit for a homepage. That is not a problem, it is a line item - as long as it surfaces at the start rather than the week before launch.
The third is access to other people’s systems. An integration with a warehouse or an accounting package needs a test account and documentation, and both sit with a company that has no reason to hurry. When I know from the brief, I request them on day one. When I find out halfway through, we wait together.
From brief to schedule - what happens next
This is the part missing from the checklists doing the rounds online. A brief does not end its life in an inbox.
The brief becomes the written scope in the offer: what exactly gets built, what is on my side and what is on yours. That scope then carries over into the contract word for word - the same text, not a summary of it. The number of items in the scope produces the schedule, with stages and with the dates on which I need a decision or material from you. That is why points five and six above matter more than they look: they do not describe the site, they set the dates.
If you are wondering how long a project like this should take and what the figure is made of, I broke that down in how much a website costs. It is worth reading before you fill in point ten.
Does the brief lock the price
It does, and that is the entire point of the document. I work fixed-bid: the figure agreed before the start does not grow during the project as long as the scope does not change. The risk that something takes longer than I estimated sits with me - that is precisely what you are paying for in this model.
So what happens when the scope does change, because a second language or an online store appears halfway through? I price that change separately and we add it to the contract as its own item with its own date. There is no situation where a cost lands on an invoice without prior agreement, and none where a scope change passes as a detail - because a detail on your side can be a week on mine.
It works the other way too. If the brief tells me you do not need a new site, only fixes to the one you have, I will say so, even when that means a smaller job.
How this works with me
A filled-in brief arrives by email. I look at the current site, check what is worth saving, and if something is missing I ask about one or two things - not twelve, which is what the list is for. Back comes a quote with a written scope, a date, and what happens after handover. With a project that has integrations I need more time, but then I tell you up front when I will get back to you.
The brief itself commits you to nothing, and neither does my look at your current site. I run web development for companies remotely, and this document is the first stage of working together rather than a filter before the conversation - which is why I would rather it were short and honest than complete.
Frequently asked questions
Does the brief have to use the developer’s form? No. Ten points in an email are worth the same as a filled-in PDF and take less time. Forms earn their keep when you send the same enquiry to several developers and want to be sure each one got an identical description.
What if I cannot answer half the questions? Leave them blank and say you do not know. A blank is information - it tells me the decision has to be made together and that it needs a slot in the schedule. An invented answer is worse than none, because it enters the quote as a fact.
Should I give a budget if the developer will just use it? Yes. A budget does not set the price, it sets the scope - it decides how many pages and features fit inside the figure you already have in mind. Without it you get an offer you reject unread, and both sides lose a week.
Does a brief replace a meeting? It cuts three meetings down to one. After a good brief the conversation is about decisions rather than gathering basics, and it usually fits in half an hour.
Looking for someone to handle it end to end? I do web development for companies with scoping and delivery run online. Let’s talk about your project.