How to Write a Brief for a Web Development Agency (With Template)

You have decided to build a web application and you are about to approach development agencies for quotes. But what exactly do you send them? A rambling email about your vision? A bulleted list of features? A Figma prototype your cousin made?

The answer is a project brief, and the quality of that document directly determines the quality of the estimates you get back. A vague brief produces vague estimates. A thorough brief produces accurate ones. It is that simple.

Yet most founders skip this step or treat it as a formality. They end up surprised when different agencies quote wildly different figures, or when the project runs over budget because "that was not in the original scope." Almost every time, the root cause is the same: the brief was not clear enough.

This guide gives you a practical template for writing a brief that development agencies will actually find useful. It is the same structure we recommend in our complete guide to building a web app, broken down into an actionable format.

Why Your Brief Matters More Than You Think

A development brief serves three purposes: it forces you to think through your project before spending money, it gives agencies a fair basis for comparison, and it becomes a reference point when someone asks "was that in scope?" This alone prevents more disputes than any contract clause.

Section 1: Project Overview

Start with the big picture. In two or three paragraphs, explain:

• What you want to build (a marketplace, a SaaS tool, a customer portal, etc.)
• Why this project exists (the business problem it solves)
• Who it is for (your target users and their primary need)

Keep it concise. This is the executive summary, not the full business plan. A developer should be able to read this section and explain your project back to you in 30 seconds.

Section 2: Target Users

Describe your primary user groups (typically 2-4). For each, cover who they are, what they need to accomplish, and how they currently solve the problem. You do not need formal personas — just be specific enough that a developer can picture the person using the app. Consider which users are essential for your MVP and which can come later.

Section 3: Core Features

This is the section agencies care about most, and where founders most often go wrong. The mistake is listing everything you could ever want rather than what you need at launch.

Use a priority system:

• Must-have: Features without which the app is useless. These define your MVP.
• Should-have: Important features that enhance the core experience but could ship in version 1.1.
• Nice-to-have: Features for the future roadmap. Include them so the agency can architect for them, but make clear they are not in scope for launch.

For each must-have feature, provide enough detail that two different developers would build roughly the same thing. "User authentication" is too vague. "Users can register with email and password, log in, reset their password via email, and manage their profile (name, photo, notification preferences)" is useful.

If you are unsure about the right level of detail, our strategy and scoping service can help you refine your feature list before you go to market with it.

Section 4: User Journeys

Walk through how a user accomplishes their primary goal, step by step. This is more valuable than a feature list because it shows how features connect.

Write one journey for each user type. For a marketplace, this might be: user creates account, browses listings, places order, receives confirmation, completes transaction. This exercise often reveals missing features or complicated flows that need simplification.

Section 5: Design Preferences

You do not need finished designs, but giving direction saves time. Share example apps you admire with specific notes ("I like Deliveroo's checkout because it is fast and simple"), any brand assets you have, the tone you want (playful consumer or serious B2B), and any hard constraints (accessibility standards, offline support).

Section 6: Technical Constraints and Integrations

List existing systems the app must integrate with, data that needs migrating, compliance requirements (GDPR, PCI DSS, NHS standards), preferred technology stack, and hosting preferences. If you are weighing technology choices, our React vs WordPress article covers when a custom stack makes sense.

Section 7: Budget and Timeline

Be honest about both. Agencies are not trying to charge you the maximum — they are trying to tell you what is realistic within your constraints.

Budget: Give a range rather than a single figure. "Our budget is £25,000-40,000" tells the agency what is feasible. If your budget is below what the project requires, a good agency will tell you and suggest ways to reduce scope. If you genuinely have no idea what to budget, say so and ask for their guidance — but read our MVP vs full product guide first so you have a baseline.

Timeline: Distinguish between "when we would like to launch" and "when we must launch." If there is a hard deadline — a trade show, a funding milestone, a seasonal window — state it clearly and explain why it matters.

Section 8: Success Metrics

How will you measure whether the project succeeded? This question is surprisingly uncommon in briefs, and it should not be.

Define 3-5 measurable outcomes. For example:

• 500 registered users within 3 months of launch
• 50 completed transactions per week by month 6
• Customer acquisition cost below £15
• Average page load time under 2 seconds
• Net Promoter Score above 40

These metrics help the agency make design and architectural decisions. An app optimised for conversion looks different from one optimised for engagement.

Common Mistakes That Waste Everyone's Time

Being too vague. "Build us an app like Uber but for dog walking" tells an agency almost nothing. Be specific about what you need.

Including everything. A 30-page brief with 200 features is overwhelming. Focus on what matters for launch.

Not stating your budget. Withholding your budget does not get you a better deal. It gets a generic estimate. Transparency leads to better outcomes.

Skipping user research. Briefs based on assumptions rather than conversations with actual users contain expensive mistakes.

The Brief Template Checklist

Use this as your final check before sending your brief:

• Project overview (what, why, who) in 2-3 paragraphs
• Target user descriptions (2-4 user types)
• Prioritised feature list (must-have, should-have, nice-to-have)
• Primary user journeys (one per user type)
• Design preferences and brand assets
• Technical constraints and integrations
• Budget range and timeline
• Success metrics (3-5 measurable outcomes)
• Competitor references
• Contact details and preferred communication method

Key Takeaways

• A thorough brief saves more money than it costs in time. Most budget overruns trace back to unclear requirements.
• Prioritise ruthlessly. A focused brief with 8 must-have features gets better results than one with 40 bullet points.
• Be honest about budget and timeline. Agencies are partners, not adversaries.
• Include user journeys, not just feature lists. They show how your app actually works.
• Define success metrics upfront so everyone is aligned on what good looks like.

Frequently Asked Questions

How long should a web development brief be?

Aim for 4-8 pages. Enough to be thorough, not so long that nobody reads it. If you find yourself going over 10 pages, you may be including too much detail at this stage — some of that belongs in a discovery phase rather than the initial brief.

Should I include wireframes or mockups?

If you have them, include them — they add clarity. But do not feel you need to create them. Rough sketches on paper, annotated screenshots of competitor apps, or even descriptive paragraphs work fine. Most agencies include a design phase in their process.

How many agencies should I send my brief to?

Three is the sweet spot. Fewer than that limits your perspective. More than that creates an evaluation burden without proportional benefit. Give each agency enough time to respond properly — at least a week.

---

A well-written brief is the foundation of a successful project. It is worth spending a week getting it right to save months of rework later. If you would like help refining your brief or exploring your project requirements, our strategy and scoping service is designed for exactly this purpose. And for the full picture of what building a web app involves, start with our complete non-technical founder's guide.