A good website brief tells developers what the site must achieve, who it is for, which pages and features it needs, who supplies the content, and what constraints apply on time and budget. With those answers on paper, every agency quotes for the same project, and you can compare proposals fairly. Without them, you are comparing guesses.
A brief does not need to be long or technical. Two to four pages written in plain language is usually enough. What matters is that it is specific.
Why does a brief change the quality of quotes?
Because the biggest source of price variation is not the agency’s rate, it is the agency’s assumptions. A brief replaces assumptions with facts.
When information is missing, careful agencies add a safety margin to cover the unknown, and less careful ones quote low and recover the difference through change requests later. Either way you pay for the vagueness. A specific brief lets serious vendors quote tightly and makes vague or padded proposals easy to spot.
It also saves time. Instead of five discovery calls repeating the same basic questions, vendors can start with the questions that are genuinely specific to your project.
What should a website brief include?
Cover these areas in this order. Each one answers a question every developer will otherwise have to ask.
Business background
Two short paragraphs on what your company does, who it serves and what makes it different. Include your current website address if you have one, and what you think works and does not work on it.
Goals and success measures
State the main job of the website in one sentence, then list how you will judge success. “Generate more dealer enquiries from Gujarat and Maharashtra” is far more useful than “look modern”. Agencies design differently for lead generation, e-commerce, recruitment or credibility.
Audience
Describe two or three types of visitors and what each needs to find or do. A purchase manager comparing suppliers behaves differently from a homeowner looking for an interior designer. Mention languages if visitors prefer Gujarati or Hindi content.
Pages and structure
List the pages you expect, grouped by type, with approximate counts for repeating pages such as products or projects. A rough sitemap is ideal, even if it is a list of headings.
Features and integrations
List each feature as a must-have or nice-to-have: enquiry forms, product filters, online payments, bookings, logins, multi-language, CRM or ERP connections. Be explicit; “and other features as needed” makes accurate quoting impossible.
Content responsibilities
Say who will provide the text, photographs, videos, product data and translations. If you need help with copywriting or photography, say so clearly, because it changes the scope significantly.
Design direction
Share your logo and brand guidelines if they exist, two or three websites you like (and what you like about them), and anything you want to avoid. Reference sites from any industry are useful; they do not need to be competitors.
Technical preferences and constraints
Mention a preferred platform if you have one, existing hosting and domain details, who controls them, and any systems the site must work with. If you do not know which platform to choose, say so and ask vendors to recommend one with reasons. Projects that need custom website development benefit most from this detail, because nothing is assumed from a template.
Timeline, budget and decision process
Give a target launch date and any hard deadlines, such as an exhibition. Sharing a budget band, even a broad one, helps agencies propose the right level of solution instead of guessing. Finally, explain who will approve designs and sign off, so vendors can plan review cycles realistically.
A fill-in website brief outline
Copy this outline into a document and answer each line. Short answers are fine; blanks are not.
- Company name and one-line description: what you do and for whom.
- Current website: URL, platform if known, what works, what does not.
- Primary goal: the single most important outcome.
- Secondary goals: up to three.
- How success will be measured: enquiries, orders, calls, applications, time saved.
- Target audiences: two or three visitor types and what each needs.
- Locations and languages: regions served and content languages.
- Page list: page types with approximate counts.
- Must-have features: listed individually.
- Nice-to-have features: listed individually, for a possible later phase.
- Integrations: CRM, ERP, payment gateway, WhatsApp, courier, email tools.
- Content: who writes copy, supplies images and prepares product data.
- Brand assets: logo files, colors, fonts, guidelines available or needed.
- Reference websites: two or three, with what you like about each.
- SEO requirements: existing rankings to protect, target services or locations.
- Hosting, domain and email: current provider and who holds access.
- Ongoing support: who will update the site after launch and whether you want a maintenance plan.
- Timeline: target launch date and fixed deadlines.
- Budget band: broad range or the level of investment you have in mind.
- Decision makers: who reviews, who approves, and how vendors will be selected.
What should you leave out?
Leave out solutions you are not sure about and detail that belongs later in the project. A brief should describe needs, not dictate implementation.
- Prescribing technology without a reason. “Must use framework X” limits good proposals unless your IT team genuinely requires it.
- Pixel-level design instructions. Share direction and references; let designers propose layouts.
- Every possible future idea as a must-have. It inflates quotes. Move ideas to the nice-to-have list.
- Internal jargon. Product codes and department nicknames confuse outside readers.
How do you compare the quotes you receive?
Check whether each proposal actually responds to your brief. The best proposals restate your goal in their own words, ask sensible follow-up questions and explain trade-offs.
Lay the proposals side by side against your must-have list and tick off what each one covers. Note anything a vendor has excluded or flagged as an assumption. Ask every shortlisted vendor the same follow-up questions in writing so answers are comparable. Be cautious of a proposal that agrees to everything without a single question; it often means the brief was not read closely.
As a hypothetical example, a Bopal-based interior design studio might find that three of four proposals include content writing while one quietly assumes the studio will supply all copy. That single difference can explain most of the gap between quotes, and the brief is what made it visible.
Key takeaways
- A specific brief makes quotes comparable by removing guesswork.
- Cover goals, audience, pages, features, content, design direction, technical constraints, timeline and budget.
- Separate must-haves from nice-to-haves to keep the first phase focused.
- Describe needs rather than dictating technology or layouts.
- Judge proposals by how well they respond to the brief, not just by price.
Next steps
Fill in the twenty-line outline above and share it with each agency you are considering. If you would like help turning your notes into a clear scope, our website design team is happy to review your draft brief and suggest what is missing.
