The quality of a web project is often decided before a single line of code is written. It's decided in the brief. A vague brief leads to misaligned expectations, scope creep and that frustrating feeling of paying for something that isn't quite what you wanted. A clear brief leads to accurate quotes, efficient delivery and a result that actually matches your vision.
I've been on the receiving end of hundreds of briefs — from one-line emails to forty-page documents. The best ones share the same qualities, and they're surprisingly simple to put together. Here's how.
Why the brief matters
When you approach a web development agency or freelancer, the brief is the foundation of every decision they make. It informs the quote, the timeline, the technology choices and the design direction. Without it, the developer is guessing — and their guesses may not match your expectations.
A brief also protects you. When scope is documented upfront, it's much harder for a project to quietly expand beyond what was agreed. And if something does change, both sides have a reference point for discussing the impact.
What to include
You don't need to write a novel. The best briefs are concise and focused on the information a developer actually needs. Here's what to cover.
About your business
Start with context. Who are you, what do you do and who are your customers? A developer building a website for a law firm will make very different design and content decisions than one building for a children's clothing brand. Don't assume they'll figure this out from your existing website — especially if your existing website doesn't represent you well.
Include:
- A brief description of your business
- Your target audience
- Your main competitors (or businesses whose websites you admire)
- What makes you different
Project goals
What should this website achieve? "We need a new website" isn't a goal. These are goals:
- Generate 20 qualified leads per month through the contact form
- Reduce customer support calls by providing self-service information
- Establish credibility with potential enterprise clients
- Sell products directly to consumers
Your goals shape every decision. A site designed to generate leads looks and works very differently from one designed to sell products.
Scope and features
Be specific about what the site needs to do. List the pages you expect and any functionality beyond static content:
- Contact form
- Blog
- E-commerce / product catalogue
- Booking or appointment system
- Client login area
- Integration with existing tools (CRM, email marketing, accounting)
- Multi-language support
If you're not sure whether you need something, say so. A good developer will help you decide — but they need to know it's being considered.
Content
Content is the number one thing that derails web projects. Be clear about:
- Who's writing the content? Are you providing all copy, or do you need the developer/agency to handle copywriting?
- What content exists already? Do you have images, logos, brand guidelines, existing text that can be reused?
- How many pages of content? A rough count helps scope the project accurately.
If you don't have content ready, say so and include content creation in the project scope. Waiting for content is the most common reason web projects deliver late.
Design preferences
You don't need to be a designer to communicate what you like. Share:
- Links to websites you admire (and what specifically you like about them)
- Links to websites you don't like (equally useful)
- Any brand assets: logos, colour palettes, brand guidelines
- Preferences: minimal vs. rich, corporate vs. casual, image-heavy vs. text-focused
Budget and timeline
This is where many businesses hesitate, but being upfront about budget saves everyone time. You don't need to state an exact figure — a range is fine. Saying "we're looking to spend between £5,000 and £10,000" is infinitely more useful than "what would it cost?" because it tells the developer what kind of solution is realistic.
Similarly, if you have a deadline — a product launch, an event, a seasonal campaign — state it. This helps the developer plan realistically and flag if the timeline is too tight for the scope.
Ongoing requirements
What happens after launch? Make clear whether you need:
- Ongoing hosting and maintenance
- Content management capabilities (so your team can update the site)
- Analytics and reporting
- SEO and marketing support
- Regular design or feature updates
At Inlucent we include ongoing support and maintenance in our plans because we've found that post-launch is where most of the value is created. Read more about why measurement and iteration matter.
The template
Here's a ready-to-use template. Copy it, fill it in and send it to any developer or agency.
Web Project Brief
Company name: Contact person and email: Date:
1. About your business
- What does your business do?
- Who are your customers?
- Who are your main competitors?
- What makes you different?
2. Project goals
- What should this website achieve? (List 2-3 specific goals)
3. Existing website
- Current URL (if applicable):
- What works about the current site?
- What doesn't work?
4. Scope
- Expected pages: (e.g., Home, About, Services, Blog, Contact)
- Required features: (e.g., contact form, blog, e-commerce, booking)
- Integrations: (e.g., CRM, email marketing, payment processing)
5. Content
- Who will provide the written content?
- Do you have images, logos and brand guidelines ready?
- Approximately how many pages of content?
6. Design
- Links to websites you like (and why):
- Links to websites you dislike (and why):
- Brand assets available: (logo, colours, fonts, guidelines)
- Overall feel: (e.g., minimal, bold, corporate, friendly)
7. Budget
- Budget range:
8. Timeline
- Desired launch date:
- Any hard deadlines? (events, campaigns, etc.)
9. After launch
- Do you need ongoing maintenance and hosting?
- Does your team need to update content independently?
- Do you need analytics and reporting?
- Are you interested in SEO or marketing support?
10. Anything else
- Is there anything else we should know?
Tips for a better brief
- Be honest about what you don't know. Saying "I'm not sure if we need e-commerce yet" is more helpful than leaving it out entirely.
- Don't over-specify the solution. Tell the developer what problem you're solving, not how to solve it. "We need customers to book appointments online" is better than "we need a calendar widget in the sidebar."
- Include stakeholders early. If someone else in your organisation needs to approve the website, involve them in the brief. Discovering new requirements halfway through a project is expensive.
- Keep it under two pages. If your brief is longer than that, you're probably including information that belongs in the project itself rather than the brief.
A good brief is a gift to both sides. It helps you think clearly about what you need, and it helps your developer deliver exactly that. If you'd like help refining yours, send it our way — we're always happy to talk through it.