Introduction
A vague website request produces vague quotes.
If one developer assumes a custom design and another assumes a template, their prices may be impossible to compare even though both say they can build the website.
A useful project brief does not need technical language.
It needs enough business detail for a developer to understand the problem, scope and constraints.
Start With the Business Goal
Explain what the website needs to achieve.
Examples include generating qualified leads, replacing an outdated site, selling products, supporting bookings or improving credibility.
Goals guide design and technical decisions.
A brief should not begin with 'we need a modern website' and stop there.
Describe the Audience
Who will use the website?
Include relevant customer types, locations, business size or buying context.
A site aimed at procurement teams needs a different experience from one aimed at consumers buying clothing.
Audience information helps the developer prioritize content and conversion paths.
List the Main Pages
Provide a rough page list if you know it.
Typical pages might include Home, About, Services, Portfolio, Case Studies, Blog and Contact.
Do not worry if the final information architecture changes after discovery.
The list gives developers an initial scope.
Describe Required Features
List features such as forms, booking, ecommerce, user accounts, multilingual content, calculators, search or document downloads.
Explain what the feature needs to do rather than naming a plugin you found online.
Developers can then recommend the implementation.
Separate essential requirements from nice-to-have ideas.
Identify Integrations
Mention CRM, email marketing, payments, inventory, analytics, maps, accounting or other systems the website must connect to.
Include existing provider names when known.
Integrations can change project complexity significantly.
They should not appear for the first time one day before launch.
Clarify Content Responsibilities
State who will provide copy, images, product data, legal policies and translations.
Content delays are one of the most common reasons website timelines slip.
If you need the developer or agency to create or migrate content, include that in the scope.
Also explain whether existing content needs to be preserved for SEO.
Share Examples You Like and Dislike
Provide a few reference websites and explain what you like about them.
Is it the navigation, typography, animation, product layout or tone?
Also share examples that feel wrong.
This is more useful than asking a developer to copy another site.
Give a Realistic Budget Range
A budget helps developers recommend an appropriate approach.
Without it, a provider may propose a custom build when a simpler solution would fit the business—or vice versa.
Budget does not need to be exact.
Provide a realistic range and ask what can be achieved within it.
Explain Timeline and Constraints
If the site must launch before an event, campaign or business deadline, state it early.
Include approval availability and any dependencies on other suppliers.
Ask the developer to identify which milestones depend on your feedback.
A realistic timeline is a shared responsibility.
Frequently Asked Questions
Do I need to know the technology before writing a brief? — No. Describe the business requirements and let developers recommend the stack.
Should I include budget? — A realistic range helps providers propose solutions that match your expectations.
How detailed should the page list be? — Enough to estimate the scope. It can be refined during discovery.
Should SEO requirements be included? — Yes, especially if replacing an existing site or targeting organic search.