How to prepare your website brief so it turns out right first time

Many web projects that go off the rails don’t do so for lack of technical talent, but because at the start nobody made clear what needed to be built. The client had one idea in their head, the developer understood another, and the differences surface once the website is already built: last-minute changes, delays, growing budgets and frustration on both sides.

The tool to avoid this is simple and doesn’t require any programming knowledge: a good brief. In this article I explain what information to prepare before talking to a developer, why each point matters, and I give you a template in list form to fill in. If you’re still deciding who to work with, pair it with the guide on how to choose a web developer.

A brief is a short document in which you set out what you want to achieve with your website, who it’s for, what it should include and what resources you have. It isn’t a contract or a technical specification: it’s the starting point that lets the professional understand your business and make you a proposal grounded in reality.

Having it ready brings very concrete benefits:

• You get quotes you can compare, because every professional starts from the same information.
• The first meeting is productive: you talk about your business, not basic questions.
• There are fewer mid-project changes, which are what blow up timelines and costs.
• It forces you to make decisions that will have to be made sooner or later, better now than with the website half built.

It doesn’t need to be perfect or use technical terms. A two or three page document, written in your own words, is worth far more than a vague idea explained from memory on a call.

This is the most important part and the one most often skipped. “I want a modern website” isn’t a goal; “I want customers to be able to book without phoning” or “I want more quote requests from companies” are. The goal shapes the design, structure, copy and features.

Try to answer these questions:

• What main action do you want visitors to take? Call, request a quote, book, buy, subscribe…
• How will you know in six months whether the website works? Think of something measurable: enquiries, bookings, sales.
• Who is your ideal customer? Whether they’re an individual or a business, what problem they have and what worries them before hiring you.
• Where will they look for you from? On their phone, in your city, from other countries…
• What sets you apart from the competition, and why do your existing customers choose you?

If the website needs to win customers from Google, say so from the outset. Planning a website with SEO built into its structure is not the same as trying to rank it once it’s finished.

References save hours of explanation. Gather three to five websites you like, not necessarily from your sector, and note exactly what you like about each one: the colours, the way services are presented, how easy it is to book, the tone of the copy. A link with no comment says little; “I like how this site shows prices without being overwhelming” says a lot.

Add the opposite too: websites you don’t like or things you want to avoid. And don’t forget your direct competitors: knowing what other businesses in your area are doing helps you find a way to stand out instead of looking like everyone else.

If you already have a brand identity (logo, colours, fonts, style guide), include it. If you don’t, say so as well: it can be part of the project or be sorted out beforehand, but it affects the work plan.

Content is one of the most common bottlenecks in a web project. The website can be technically ready and then wait weeks for the service descriptions or the team photos to arrive. That’s why the brief needs to make clear what already exists, what’s missing and who is responsible for each item:

• Copy: will you write it, reuse it from your current website or need someone to write it?
• Photography: do you have good-quality photos of your own, or will you need a photo shoot or stock images?
• Logo and brand assets in high resolution, ideally in vector format.
• Special content: product catalogue, prices, past projects, FAQs, videos.
• Languages: will the website be in Spanish only, or do you need other versions from the start?
• Your company details for the legal notice and privacy policy.

This is where it’s easy to ask for everything. The trick is to separate what the website needs to meet its goal from day one from what would be nice to have later on. That way the budget goes on what adds value and the rest can be planned in phases. Some questions worth answering:

• Do you need contact or quote request forms? Where should those requests go?
• Online bookings or appointments, product sales, payments, a private customer area?
• Does it need to connect to tools you already use: CRM, invoicing software, newsletter, calendar, WhatsApp?
• Who will update the website and how often? This affects the technology and the admin panel.
• Are there accessibility requirements? The benchmark is the W3C’s WCAG guidelines, and it pays to take them into account from the design stage.

Sort the list into two columns, must-have and nice-to-have, and don’t worry if you don’t know how each thing is done technically. Your job is to explain what you need; the developer’s job is to propose the best way to solve it and tell you what it involves.

Many people avoid giving a budget for fear the professional will simply “match” that figure. In reality the opposite happens: without an indicative range, the developer has to guess whether you’re thinking of a simple website or a custom project, and the proposals you receive can be impossible to compare. With a range, they can propose the best solution within your reality and, if it doesn’t stretch to everything, prioritise.

If you have no idea what figures to work with, in the article on how much a website costs I explain what drives the price. As for timing, think about:

• Your preferred launch date, and whether there’s a reason behind it (an opening, a campaign, a trade fair) or it’s flexible.
• Your real availability for meetings, reviews and delivering content.
• What happens after launch: who maintains the website, who updates it and whether improvements will come in phases.

One tip: if the date can’t move, say so clearly. It’s better to launch a solid first version with the essentials on time than to delay everything by trying to do too much.

It looks like a minor detail and it causes a lot of delays. If three partners, a family member and the marketing person all have opinions in your business, and each reviews separately, the project fills up with contradictory changes. Before you start, define:

1. 1One point of contact who centralises communication with the developer.
2. 2Who has the final say on design, copy and budget.
3. 3How feedback will be collected at each review: in a single document and all at once, not in scattered messages.
4. 4How many review rounds are expected at each stage.

And when the website is nearly ready, the website launch checklist will help you make sure nothing important is left out before it goes live.

Copy this list into a document and answer each point in your own words. If you don’t know something, write “I don’t know”: that’s useful information for the developer too.

1. 1Your business: what you do, where you work and which services or products matter most.
2. 2Current situation: do you have a website? What works and what doesn’t? Do you have your own domain, hosting and email, in your name?
3. 3Main goal: the action visitors should take and how you’ll measure success.
4. 4Audience: your ideal customer, their needs and where they look for you from.
5. 5What sets you apart: why customers choose you and what distinguishes you from the competition.
6. 6Competitors: two or three direct competitors and their websites.
7. 7References: three to five websites you like, with the reason, and one or two you don’t.
8. 8Brand: logo, colours, fonts and tone of voice.
9. 9Structure: the pages or sections you imagine (home, services, about, blog, contact…).
10. 10Content: what you already have, what’s missing and who will prepare it, with dates.
11. 11Features: must-haves and nice-to-haves, plus integrations with other tools.
12. 12Languages: main language and any additional versions.
13. 13Timeline: preferred date and whether it’s fixed or flexible.
14. 14Budget: indicative range and whether you’d consider working in phases.
15. 15After launch: maintenance, updates and who takes care of them.
16. 16Decision-making: point of contact, who approves and how reviews work.

You don’t have to fill it in all in one go. The most practical approach is to write a first draft, leave it for a couple of days and then go over it with the people who will make the decisions. Rereading it often raises questions worth settling before you ask for quotes: whether you really need an online shop or a catalogue will do, whether you’ll keep the blog going, or whether the website has to be bilingual from the start.

Send the same document to every professional you talk to. That way you can compare proposals fairly and notice something that says a lot about each of them: who asks good questions about your business and who just sends a number.

Preparing a good brief takes little time and completely changes how a web project unfolds. When the goal, audience, content, features, budget and decision-making are clear from the start, the developer can propose the right thing, you know what to expect, and the website turns out right first time, with no reworking and no surprises on the invoice.

I’m Elmar Mamedova, a full stack developer based in Málaga, and on every project I start by understanding the business before talking about technology. If you like, we can go through your brief together and turn it into a realistic web development plan, with clear priorities and no small print.