The projects that go smoothly for me almost always start the same way: the client sends a short, clear brief before we talk about price. The ones that drag on usually start with a single line like "I need a website for my business, how much?" There's nothing wrong with that message, but it means the real details come out slowly over weeks, and every new detail changes the work.
You don't need to be technical to write a good website brief. It's one or two pages in plain words that answer the questions any developer will ask anyway. In this post I'll go through what I like to see in a brief, a simple template you can copy, and the mistakes that cause the most back and forth.
Why a brief saves time and money
When I quote without a brief, I have to guess. If I guess low, the project turns into arguments about what was included. If I guess high, the client goes elsewhere. A brief removes most of the guessing. It also lets you send the same document to two or three developers and compare their quotes properly, because they're all pricing the same thing.
A brief also helps you. Writing it forces you to decide what the website is actually for, which pages you need and what you'll provide yourself. Many owners realise halfway through writing it that they need fewer pages than they thought, or that the photos they planned to use don't exist yet.
What to put in your website brief
1. Your business in a few sentences
What you do, where you work and who your customers are. Keep it short. "We're a family-run dental clinic in Lahore, most of our patients live within 10 km, and many find us on Google Maps" tells me more than a long company history.
2. The main goal of the site
Pick one main action you want visitors to take: call you, message on WhatsApp, fill in a form, book an appointment or buy something. Everything else on the site should support that action. If you have a second goal, write it down too, but rank them.
If you already have a website, say what's wrong with it today. "It doesn't work well on phones" or "nobody fills in the form" is useful information.
3. The pages you think you need
A simple list is enough: Home, About, one page per main service, Gallery, Contact. Don't worry if it's not final. I usually suggest changes, like giving each service its own page because people search for services separately. I wrote more about this in my post on planning a small business website.
4. Features beyond basic pages
This is the part that changes the price the most, so be specific. Some examples:
- Do you want to edit prices, photos or blog posts yourself after launch?
- Do you need online booking, payments or customer logins?
- Should the site be in more than one language?
- Does it need to connect to anything you already use, like a booking system, a CRM or Google Sheets?
If you're not sure whether you need something, write it as a question. That's much better than leaving it out and asking for it after the work has started.
5. Content and photos
Say who is writing the text and who is supplying the photos. Waiting for content is the most common reason projects run late, in my experience. If you have real photos of your team, shop or work, mention them. Real photos almost always work better than stock images for a local business.
6. Examples you like and dislike
Two or three links to websites you like, with one line on what you like about each. "I like how simple the menu is" or "I like that the prices are easy to find" is far more helpful than "make it modern". A site you don't like is useful too, as long as you say why.
7. Domain, hosting and email
Do you already own a domain? Who has the login? Do you have hosting and business email, and do they need to keep working during the change? This sounds boring, but a lost domain login can hold up a launch for days.
8. Deadline and budget range
Give a real deadline if there is one, like a shop opening or an event, and say if the date is fixed or flexible. Then give a budget range. Many people leave this out because they worry they'll be charged the maximum. In practice, a range helps a developer suggest what fits. A five-page site with a contact form and a full web app with logins are very different jobs, and the budget tells me which direction to think in.
9. Who looks after the site after launch
Will you update it yourself, ask the developer for changes now and then, or want a monthly maintenance plan? This affects how I build the admin area and which tools I choose.
A simple website brief template
You can copy this into an email or a document and fill it in. Short answers are fine.
- Business: what you do, where, and who your customers are.
- Main goal: the one action visitors should take.
- Current site: the link, and what's not working.
- Pages: your list of pages.
- Features: editing, booking, payments, logins, languages, connections.
- Content: who writes the text and who supplies photos.
- Examples: two or three sites and what you like about each.
- Domain and hosting: what you have and who has access.
- Deadline: the date and whether it's fixed.
- Budget range: a rough minimum and maximum.
- After launch: who will update and maintain the site.
Mistakes I see in briefs
Too much about design, too little about the business
Colour and font choices matter, but they're easy to change. What's hard to change later is the structure, the features and the content plan. A brief that's mostly about colours usually leaves out the things that affect the price.
"Like Amazon, but simpler"
Comparing your project to a huge website doesn't help much, because nobody knows which parts you mean. Describe the actual features you want instead: product pages, a cart, cash on delivery, an order email to you.
Leaving out the hard parts
Sometimes a client mentions after the quote that they need 200 products imported from an old site, or that their old pages must keep their Google rankings. Those things are fine, but they take real time. Put them in the brief so they're in the quote.
Writing a 20-page document
A very long brief can be as hard to work with as no brief. If it's longer than two pages, it's probably mixing must-haves with ideas for later. Split it into "needed for launch" and "maybe later". That alone often brings the first quote down.
What happens after you send it
When I get a brief, I read it fully and then reply with questions about anything that isn't clear. Expect a few questions from any careful developer. If someone quotes a fixed price within minutes without asking anything, they're probably guessing too.
Once the questions are answered, I write the scope back in plain words: the pages, the features, what the client provides, the timeline and the price. That written scope is what we both refer to during the project, and it's built almost entirely from the brief.
If you're planning a website and want a second opinion, write a brief using the template above and send it to me. Even if we don't end up working together, you'll have a document you can use with any developer.
Back to Blogs