How to write a website brief so you don't overpay

On one of the first projects where I owned the frontend, the brief had a line: "Convenient site search." I built a search bar in the header with suggestions. Two weeks later the client looked at it and asked where the price and city filters were. By "search" he meant a catalogue with filters. That was another week of work nobody had put in the estimate.

Nobody was at fault. Two people simply read the same word differently.

Since then I've treated a brief not as paperwork but as a way to save the client's money. A good website brief doesn't have to be long. One page is enough for us, as long as it has the right things on it.

Why write a brief if we can just get on a call

The call matters. But a month later nobody remembers what was agreed on it. A brief pins the agreement down, and you can go back to it when the "but we said…" argument starts.

There's a practical side too. We estimate in hours. If the brief says "user account", that can be 20 hours or 200. When a requirement is vague, the contractor adds a buffer. An honest one adds a reasonable buffer, a dishonest one picks a number out of the air. Either way, you're paying for the uncertainty.

A one-page brief template

This is the template we send to clients. Copy it and fill it in your own words, no technical terms. If you don't have an answer for something, write "don't know". That's an answer too, and we'll talk it through.

1. About the company: what we do, for whom, in which city/countries.
2. Goal of the site: one main goal (enquiries / trust / sales / hiring).
3. Target action: what should a visitor do? Where does the enquiry go?
4. Audience: who they are, which device, which language they read.
5. Languages: uz (Latin/Cyrillic), ru, en — which ones at launch.
6. Pages: list of sections. What gets updated often, and by whom.
7. Features: catalogue, filters, payment, booking, calculator, accounts.
8. Content: do you have copy, photos, video, logo, brand book.
9. Examples: 3 sites you like, 1 you don't, and why.
10. Timing and budget: by what date and in what range.
11. Access: do you have a domain and hosting, in whose name.

Eleven points. A client usually fills it in within half an hour. The ones that matter most are 2, 3 and 7. If those answers are clear, the rest can be refined as we go.

Vague vs precise: examples from real briefs

The most common problem isn't that something is missing from the brief. It's words that sound specific but mean nothing: "modern", "convenient", "like our competitors", "responsive". Below are pairs from briefs we've received, with how we rewrote them together with the client.

The last row is almost word for word the task from IBN Express, a US car-shipping company. It was clear from day one that the "calculator" was the heart of the site, and we budgeted time for it separately: US ZIP autocomplete, saving the lead, posting it to the sales team's Telegram channel. If the brief had just said "calculator", the estimate would have been off several times over.

What we ask in the first Telegram chat

Most clients reach us through Telegram, and the first conversation often happens right there, in text or voice messages. We don't start with the price. We ask a few questions first, and the answers already tell us what kind of project this is.

A lot of people get shy at question six. They shouldn't. If you say "up to $1,500", we'll propose the best thing that can be built for that money instead of drawing up a $5,000 project you'll end up turning down. You'll find price reference points on our web development page.

What not to put in a brief

Some things make the document longer without helping.

Technologies. If you're not a developer, don't write "in React" or "on WordPress". Write what matters to you: the site should open fast, be editable without a programmer, and be maintainable by a different contractor a year from now. We'll pick the stack for those requirements. For example, we built the Japanese Garden site as a PWA that works offline: a visitor in the garden sees opening hours, tickets and tea ceremonies even when the connection drops. The word "PWA" wasn't in the requirements, and it didn't need to be. What the visitor needed was.

HEX colours without a brand. If there's no brand book, it's better to say "we like calm, green, close to nature" and show examples. A designer will turn that into a palette better than a random #3A7F2C.

Forty pages about each section. At the brief stage, a list of sections with one line each is enough. Details come at the prototype stage.

What happens to the brief next

The brief isn't the final document. We take your page, ask follow-up questions, and turn it into a prototype: grey screens with no design, showing the structure and the user's path. Murodjon usually works on the prototype, and that's where the things nobody thought of come up. On PlanBaby, for instance, one product holds articles, stories, a baby-name database, tools and a shop with a cart. In a brief that's five lines. In a prototype you see straight away where those sections overlap and where the user goes next.

After the prototype, the estimate becomes precise, and the contract describes what will actually be built.

My advice is simple: don't hunt the internet for the perfect thirty-page brief template. Fill in the eleven points above honestly, especially the goal and the target action. That will save you more than any haggling over price.