A message that says “we need a website, how much?” cannot be quoted honestly. The developer either guesses a number or asks twenty questions, and a week goes into back and forth. A brief exists so that those answers are there before the first call.
A good brief does not have to be long. It describes the task, the pages, what already exists, and the limits. Below is a walk through each part and a short template at the end that you can copy and fill in.
The task in one paragraph
Start with why the business needs the site. Who arrives, what that person should do, and how you will know the site works. “A client from search finds the service, sees examples of work, and sends a request to Telegram” is a task. “We want a modern website” is still a wish.
If the new site replaces an old one, say what gets in the way in the old one. That often matters more than a list of things you like on other sites.
Pages and what goes on them
List the pages you have in mind: home, services, work, contact, blog. One line for each about what it should contain. You do not need to draw a layout. The developer needs to see the scope: five pages and forty pages are quoted differently.
If you are not sure about the structure, say so. Proposing a structure is work too, and it is better as a separate line in the quote than a surprise halfway through.
What already exists
- Domain and hosting: do you have them, whose name are they in
- Logo, brand colors, fonts
- Copy: ready, drafts, or written from scratch
- Photos of the product, the team, the place
- An old site with content that has to move over
Every missing item becomes either work or waiting. It is better to say so up front than to find out during the build that there are no photos and never will be.
Examples and counterexamples
Two or three sites you like, with one sentence about each: what exactly you like. The colors, the way work is shown, a short form, how the catalog is organized. A bare link says little, because on the same site you may notice the font while the developer looks at the menu.
A site you dislike, and why, is just as useful. It rules out directions that would otherwise eat time.
Requests, payment, and connections
Where requests should arrive: email, Telegram, a CRM. Whether payment happens on the site or an invoice after a call is enough. Whether there is an accounting or inventory system the site has to exchange data with. Integrations often take longer than the pages themselves, so name them in the brief even if you have not decided whether you need them.
Timing and budget
If the date is tied to an event, name it: an opening, a trade show, a season. “As soon as possible” does not help planning. “Before the shop opens” does.
You do not have to name a budget, but a range saves time on both sides. The same task can be solved in a simple way and an extended way, and it is easier to show you the one that fits from the start.
What the brief does not need
- Vague words like “stylish, modern, user friendly,” which mean nothing without examples
- A technical specification copied from someone else’s project
- A choice of technology, unless you have a real reason to require it
- A list of features “for later” that nobody plans to build now
A short template
- Business and audience: who you are and who the site is for
- The main action a visitor should take
- List of pages, one line each
- What exists: domain, hosting, logo, copy, photos
- Three examples with a note each, and one counterexample
- Where requests go, whether payment and integrations are needed
- The date and what it is tied to
- A budget range, if you are ready to share it
A brief like this takes an evening. It is enough for a quote that shows what is included in the work and what is not.
How the answers in a brief turn into quote lines is covered in the note on what a site costs. If the site is a single page, see the landing structure. When the brief is ready, send it through the contact form.