How to Brief a Development Agency: A Scope Document Template

Why Most Briefs Fail Before They’re Sent

The most common mistake in briefing a development agency isn’t leaving something out — it’s conflating a business problem with a solution. A brief that reads “we need a mobile app” has already decided on the solution before anyone has explored whether the problem requires one. A good agency should challenge the solution assumption, but they can only do that if you’ve described the problem rather than prescribed the output.

The second most common mistake is treating a brief as a requirements document rather than a communication tool. A brief doesn’t need to answer every technical question — that’s what the discovery phase is for. What it must do is give agencies enough context to assess whether they can help, what scope that help represents, and whether there’s a commercial fit worth pursuing. Think of a strong brief as your sales pitch to the agency — you’re trying to attract the right fit, not just any respondent.

Section 1: Background and Context

Describe your company, the problem you're solving, and the business context for this project. Include:

• What your business does and who your customers are
• The specific problem this project solves (not just "we need a website")
• Any existing systems it needs to integrate with or replace
• Why this project, why now

Section 2: Objectives and Success Metrics

Define what success looks like in measurable terms. "We want a better website" is not a success metric. Examples of usable objectives:

• Reduce checkout drop-off rate from 72% to under 55% within 3 months of launch
• Enable content team to publish articles without developer involvement
• Support 10,000 concurrent users without performance degradation
• Complete booking flow in under 90 seconds on mobile

Section 3: Functional Requirements

List what the system needs to do. Organise by user type (admin, customer, staff) and priority (must-have vs nice-to-have). Use user story format where possible: “As a [user type], I want to [action], so that [outcome].” This is the section most briefs skip — and the source of most disagreements.

When writing user stories, the “so that” clause is the most important part — it articulates the business value, not just the action. A story without a “so that” clause is a feature request; one with it is a requirement with traceable business justification. If a feature can’t be justified with a “so that” clause, it probably doesn’t belong in the initial scope.

Divide requirements into three tiers: core (the product fails without it), standard (expected but the product can launch without it), and enhanced (nice-to-have for subsequent phases). This tiering directly maps to how agencies build phased delivery plans and is the single most useful input for getting realistic scope estimates across multiple proposals.

“Requirements instability is the leading cause of project overruns. A project that changes requirements mid-build doesn’t need better engineers — it needs a better brief.”

Section 4: Technical Requirements and Constraints

This section prevents the most common and expensive surprises in development projects. Unknown integrations, undiscovered compliance requirements, and unstated hosting constraints discovered mid-build are the leading causes of project overruns.

• Preferred tech stack (or “open to recommendations”)
• Existing systems the solution must integrate with (CRM, ERP, payment gateways)
• Hosting preferences (cloud provider, on-premise, shared hosting)
• Security and compliance requirements (PCI-DSS, GDPR, SOC 2)
• Performance benchmarks (page load times, uptime SLA)
• Browser and device support requirements
• Accessibility standard required (WCAG 2.1 AA is now mandatory in many jurisdictions)

Section 5: Design and Brand Guidelines

Include links to existing brand assets, style guides, or design systems. If you have preferences for reference sites (“we like the UX of X, the visual style of Y”), document them with specific notes on what you like and don’t like. Agencies waste significant time presenting work in the wrong visual direction because the brief didn’t include enough reference material. More is better here — screenshots, URLs, and written notes on what specifically you’re drawn to.

If your business has no existing brand guidelines, state that clearly. A good agency will either include brand development in scope or recommend it as a prerequisite. Expecting a visual outcome without brand definition is a recipe for revision cycles.

Section 6: Timeline, Budget, and Decision Criteria

• Timeline: Hard deadlines (product launch, contract expiry) and preferred go-live target
• Budget range: Yes, share it. Agencies calibrate scope and team to budget. Hiding it wastes everyone's time.
• Decision criteria: How will you evaluate proposals? Price, team experience, process, references?
• Who decides: Who signs off on the agency selection and on deliverables during the project?

The Budget Conversation Most Clients Get Wrong

Withholding your budget from a development brief is the single most counterproductive decision a client can make. It doesn’t protect your negotiating position — agencies don’t reduce their rates when they don’t know your budget. What it does cause is agencies scoping to an imagined middle-ground budget that may be entirely misaligned with yours, producing proposals that are either vastly overpriced or conspicuously thin in scope.

Share your budget range. A range of “we’re thinking $80k–$120k depending on scope” gives an agency everything they need to present a proposal that respects your constraints while demonstrating what’s achievable. You’ll receive better scoped solutions, fewer surprises at proposal review, and a faster path to engagement — or a faster understanding that there isn’t a commercial fit, which saves everyone’s time. If you genuinely don’t know your budget, say so explicitly. A good agency will respond with ballpark ranges tied to scope options rather than a binary quote.

What Happens After You Send the Brief

The brief submission begins the engagement process, not ends it. Plan for: an initial agency clarification call (typically within 48 hours of receipt), a proposal period of 5–10 business days, and a shortlist review session with your decision-maker before selecting. Building a supplier evaluation matrix — scoring agencies on relevant dimensions including team experience, process clarity, communication quality, reference quality, and price — removes subjectivity from the selection decision and makes it defensible to internal stakeholders. Evaluate process and people as rigorously as you evaluate portfolio and price; the team you work with daily matters more than the work they’ve done for others.

Brief Completeness Checklist

Before sending your brief to agencies, confirm it covers each of these elements:

• Company background and the specific problem being solved
• Measurable success metrics with target values and timeframes
• Prioritised feature list organised by user type (must-have vs nice-to-have)
• Technical constraints, integrations, and compliance requirements listed
• Design references and brand assets attached or linked
• Realistic budget range included — not withheld
• Hard deadlines and preferred go-live date stated
• Decision-maker named and decision criteria defined