How to Write a Website Brief That Gets Accurate Quotes

The first section shouldn't mention pages or features at all. It should say what your business does, who your customers are, and what you want this website to change.

'We want a new website' is a request. 'We get most of our enquiries by phone from people who found us on Google, but the current site doesn't work on mobile and the contact form has been broken for months' is a brief. The second tells a developer what success looks like, and lets them tell you if you're about to spend money on the wrong thing.

Include how you get customers now, what your competitors do, and what specifically frustrates you about the current situation.

Functionality drives cost far more than page count. Be specific and be honest about what's essential versus aspirational.

• Contact forms — how many, what fields, where do submissions go?
• Selling — physical products, digital, services, subscriptions? How many products? How do payments work?
• Bookings or appointments, and whether they sync with anything.
• User accounts, logins or member-only content.
• Multiple languages.
• Integrations — a CRM, an accounting system, an inventory system, a payment gateway. Name them.
• Anything that has to happen automatically when someone does something.

Content is the most common reason projects overrun, and it's almost never in the brief.

• Roughly how many pages, and how many distinct kinds of page.
• Whether the content exists, needs rewriting, or needs writing from scratch — and who is doing that.
• Whether it's migrating from an existing site, and how much of it.
• Whether you have photography, or need it.
• Who will update the site afterwards, and how technical they are. This changes how the site should be built.
• If content isn't ready, say so. A developer who knows that can plan around it; one who doesn't will blame the delay on you, fairly.

'Modern and professional' describes every website ever commissioned. It tells a developer nothing.

Instead, link three or four sites you like and say what you like about each — the layout, the typography, how a particular section works. Link one or two you dislike and say why. That's far more useful than adjectives.

Say whether you have a brand: logo, colours, fonts, guidelines. If you have a designer or an existing Figma file, say so — a developer implementing a supplied design is a different job from a developer designing the site.

There's a widespread belief that naming a budget means you'll be charged all of it. In practice, withholding it means developers guess, and the guesses are wildly apart — you get quotes an order of magnitude from each other and no way to compare them.

A range is enough. It lets a developer tell you honestly whether your requirements fit, propose what to phase if they don't, and put together a proposal that's actually relevant.

If a developer's answer to your range is a considered 'here's what's achievable within it, and here's what I'd phase', that's a good sign. If it's a quote that lands exactly at your maximum regardless of scope, that's a different signal.

• Is there a real deadline, and what happens if it's missed? An event or a campaign launch is a hard date; 'as soon as possible' is not.
• Who signs off, and how quickly can they? Approval chains are the most common source of delay.
• Are there periods when you're unavailable?
• Any technical constraints: existing hosting you must stay on, a platform decided by head office, a compliance requirement.
• Any work already done that the project must build on.

Include this in the brief so it's quoted rather than discovered later.

• Who maintains the site — updates, backups, security?
• Do you want a support arrangement, and what response time do you need?
• Who hosts it, and do you want the developer to manage that?
• Will you need training, and for how many people?
• Do you expect ongoing content or feature work after launch?

A surprising number of briefs describe the business in detail and never mention the visitor. But the person the site is built for decides almost every design and content decision in it.

• Who are they, and what are they trying to do when they arrive? Comparing suppliers, checking you exist, buying something, finding a phone number?
• What do they need to know before they will contact you or buy?
• What do they ask you on the phone that the site should have answered?
• Are they on a desktop at work, or a phone on mobile data? For most Indian businesses it is overwhelmingly the second, and that changes what the site can afford to weigh.
• What do they already know, and what jargon will they not recognise?

So you can actually compare proposals, ask each developer for the same structure:

• An itemised scope — what's included, broken down.
• What's explicitly excluded. This list is often more informative than the inclusions.
• Timeline with milestones, and what they need from you at each.
• Payment structure.
• Who owns the code, hosting, domain and plugin licences at the end.
• What ongoing costs to expect.
• Two or three live examples of similar work.

Eight headings, a paragraph or two each: About the business. What we want to achieve. What the site must do. Content. Design references. Budget range. Timeline and constraints. After launch.

Two pages is plenty. It doesn't need to be polished — it needs to be specific. A developer who reads that and comes back with questions is a developer who read it, which is itself worth knowing.

If you're putting one together and want a sanity check before sending it out, send it to me and I'll tell you what's missing.