A brief is the document where you describe what you want from your site - the goal, the content, the features, the budget. It sounds dull, but it decides whether the quote will be realistic and whether the finished site will actually do what you ordered it for. A good brief saves money for both sides: I don't guess, and you don't pay for fixes that come out of misunderstandings. Below I give you a checklist of the points I want to see, plus a ready-to-copy template.
What a brief should contain - the checklist
This isn't a wish list along the lines of "make it look nice". Each point closes off a question or an argument that would otherwise come up later.
- The goal of the site and the business task. Not "what kind of site do you want", but what should change once it goes live - more enquiries, online sales, fewer phone calls about the same question. Without a goal we design a pretty brochure that brings nothing in.
- Target audience. Who will read the site: the industry, the age, whether they're businesses or individual customers, how they find you (from Google, from ads, from a referral). I write one way for a construction company, another way for a beauty salon.
- Structure and pages. A list of the pages you want: home, services, about, portfolio, contact, blog. If we don't settle this at the start, "let's add one more thing" shows up mid-project and the price climbs.
- The features you need. A form, a calculator, appointment booking, a cart and payment, login, filters. Features are the biggest part of the budget, so the sooner you list them, the more accurate the quote.
- Examples of sites you like. Two or three links with a note on what exactly you like there - the layout, the simplicity, the colours. This cuts down the rounds of revisions on the design more than any written description.
- Content - who supplies the text and photos. Whether you already have the copy and images, or you need a copywriter and a photo shoot. Missing content is the most common reason a project sits idle for weeks.
- Languages. One version or a multilingual site (Polish, English, Ukrainian). This affects the structure, the budget, and the way I build the site from day one, so it can't be "added later" for free.
- Budget and deadline. A budget range and a realistic deadline, even a rough one. Without it I'm shooting in the dark, and you get a quote that either shocks you or describes a completely different site than the one you want. More on prices in the piece on how much a website costs.
- Domain and hosting. Whether you already have a domain, where the current site is hosted, who has access. Often it's a small detail that, at the end of the project, can hold up the launch for a few days.
- Who's responsible for SEO. Whether you want the site prepared for search and who will run it afterwards - you, me, or an outside agency. SEO built in at the brief stage is cheap; bolted on after the fact, far more expensive.
- Integrations. CRM, payment system, Google Analytics, Meta pixel, newsletter, booking system. Every integration is a separate piece of work, so it has to be in the brief, not in a later message saying "oh, and let's connect this too".
Ready-to-copy brief template
Copy these questions and answer them in your own words. It doesn't have to be pretty or long - two pages of specifics is enough.
- What does your company do and how are you different from your competitors?
- Why do you need a new site - what should change once it's live?
- Who is your customer and how do they end up on the site?
- Which pages do you want?
- Which features are essential (form, payment, booking, calculator)?
- Give 2-3 sites you like and say why.
- Do you already have the text and photos, or do you need help?
- How many language versions?
- What's your budget and by when should the site be ready?
- Do you have a domain and hosting? Where is the current site hosted?
- Who will handle SEO and run the site after launch?
- Which systems need to be connected (CRM, payments, analytics, newsletter)?
If you don't know the answer to some of the questions - that's information too. Then we'll simply go through them together on the first call.
Brief vs. full specification - how they differ and when to use which
This is where people most often get confused, so I'll separate the two plainly.
The client writes the brief. It's their view of the project: goals, audience, features, budget, examples. The language is human, not technical. A brief answers the question "what do I want and why". It's enough for a quote and for smaller projects - a company site, a landing page, a simple blog.
A full technical specification comes later, and the developer writes it, ideally together with you. It's the brief broken down into specifics: exactly how each form works, what happens after a click, how the CRM integration looks, what the requirements are for speed and devices. The specification answers the question "how should this work in detail". You need it on bigger projects - a shop, a portal, a site with login and payments - because that's where unspoken assumptions cost the most.
In practice it goes like this: you give the brief, I make a quote from it, and on a complex project we nail down the detailed brief together before we start. How that order affects the timeline I covered in the piece on the stages and timelines of building a site.
A good brief is also a sign you've found a sensible developer - if someone quotes a site without asking these questions, it's worth pausing to think. What else to watch for, I gathered in the guide on how to choose a web developer.
FAQ
What should a website brief contain?
The business goal of the site, the target audience, the list of pages, the features you need, examples of sites you like, information about the text and photos, the languages, the budget and deadline, details about the domain and hosting, and the integrations you need. That's the minimum that lets me make a realistic quote without guessing.
Do I really need a brief if I can just tell you what I want?
A conversation is great, but it slips away. A brief records the decisions both sides can come back to when an argument turns up along the lines of "but that's not what we agreed". Without it, you almost always end up with revisions someone has to pay for - usually you.
Who writes the brief and who writes the specification?
The client writes the brief, in their own words, because it's a description of their business and their expectations. The developer writes the full technical specification, ideally together with the client, because it takes knowledge of how things work on the technical side.
How long should a brief be?
Short and specific. Two, three A4 pages at most. A few sentences to the point beat ten pages of generalities like "modern and professional". What counts is the specifics, not the length.
What if I don't know the answer to some of the brief questions?
That's normal, especially with a first site. Leave those spots blank and flag them. We'll go through them together on the call - that's often the most interesting part, because that's when things come out that you hadn't thought about before.
Does the brief affect the price of the site?
Yes, a lot. The more detailed the brief, the more accurate the quote. A vague brief forces a quote padded for the unknown, or later top-ups when features turn up that weren't on the list.
Can I change my mind after sending the brief?
Of course, a brief is a starting point, not a contract carved in stone. Small changes at the planning stage are natural. The problem only starts with big changes of direction while the site is being built - which is exactly why it's worth thinking the basics through right at the start.
Got an idea for a site but not sure how to turn it into a brief? Write to me - we'll go through these points together. I've described the scope of the service on the website development page.
