Send three developers a vague brief and you'll get three quotes that differ by a factor of five — not because anyone is wrong, but because each one imagined a different project. A good brief fixes that. It takes an hour or two to write and saves weeks of back-and-forth.
This is the structure I'd like every client to send me. Copy it, fill it in, and send the same document to everyone you're talking to.
Why a brief matters more than a budget
A budget tells the developer how much you want to spend. A brief tells them what you need. Without the second, the first is just a number to aim at. With both, you get a quote that explains what you get for the money, and you can compare quotes line by line.
What to put in a website brief
1. About you, in three sentences
Who you are, what you sell, and who buys it. Skip the company history. "We're a two-person design studio in Belgrade selling custom furniture to restaurants" is perfect.
2. The goal of the website
Pick one primary goal and at most two secondary ones:
- Generate enquiries or bookings
- Sell products online
- Build credibility (portfolio, case studies)
- Recruit
- Explain a product so people sign up
Then attach a number if you can: "20 qualified enquiries a month" beats "more leads".
3. The audience
Who visits, what they want to find, and what makes them leave. Two or three short descriptions are enough: "Restaurant owners, 35–55, on their phone between services, want to see prices and lead times quickly."
4. Pages and features
List the pages you expect and, separately, anything that does something:
- Contact or booking form (where should submissions go?)
- Online payments or a shop (how many products? variants?)
- Blog or news (who writes it, how often?)
- Multiple languages (which ones, and who translates?)
- Accounts or member areas
- Integrations: CRM, newsletter, calendar, analytics
Features drive cost far more than pages, so be specific here.
5. Content: who provides what
For each page, note whether you provide the text, images and video, or need them created. Missing content is the most common reason websites launch late.
6. Design direction
Share three to five websites you like and, for each, what you like about it — the typography, the calm layout, the way the product photos are shown. Add one site you dislike and why. If you have a logo and brand guidelines, attach them; if not, say so, because brand work is a separate piece of work (see what brand identity a startup needs at launch).
7. Technical requirements
- Do you have a domain? Hosting?
- Who will edit the site after launch, and how technical are they?
- Anything that must stay: an existing shop, booking system, email setup?
- SEO: are you replacing a site that already ranks? (Then redirects matter.)
8. Budget and timeline
Give a range, not a single figure, and say whether the date is fixed (a launch event, a trade fair) or flexible. A range lets a developer propose what fits inside it instead of guessing.
9. How you'll decide
Who approves designs and how quickly? One decision-maker who replies within a day is worth more than any project-management tool.
What to leave out
- Technology choices you don't have a reason for. Say "the team must be able to edit pages without a developer" rather than naming a CMS, unless you already use one.
- A full sitemap of 40 pages. Start with the pages that serve the main goal; more can follow.
- Every idea you've ever had. Put nice-to-haves in their own list so they can be priced separately.
The template
Copy this into a document and fill it in:
# Website brief — [Company name]
## About us
[Three sentences: who you are, what you sell, who buys it]
## Goal
Primary: [one goal + a number if possible]
Secondary: [up to two]
## Audience
- [Visitor type 1: who, what they look for, what makes them leave]
- [Visitor type 2]
## Pages
- [Page]: [purpose]
## Features
- [Feature]: [details, e.g. "contact form → email to sales@"]
## Content
| Page | Text | Images | Video |
| ---- | ---- | ------ | ----- |
| Home | we provide | need photos | — |
## Design direction
- Like: [URL] — [what exactly]
- Dislike: [URL] — [why]
- Brand assets: [attached / none yet]
## Technical
Domain: [yes/no] · Hosting: [yes/no] · Editors after launch: [who]
Must keep: [existing systems]
Replacing a ranking site: [yes/no]
## Budget and timeline
Budget range: [from–to] · Launch: [date, fixed or flexible]
## Decisions
Decision-maker: [name] · Typical response time: [e.g. 1 day]
## Nice to have (price separately)
- [...]What happens next
With a brief like this, a good developer can reply with a scoped proposal rather than a list of questions: what's included, what isn't, a timeline, and a price for each part. If two quotes still differ a lot, ask each to explain the biggest line item — you'll learn more from that conversation than from the totals.
Building an app rather than a website? The same principles apply, with more emphasis on user flows — see how much an MVP really costs.
Have a brief ready? Send it over.
