How to Brief a Web Development Agency Properly

A UK-included study of 600 software engineers — 250 of them British, surveyed to British Polling Council standards — put a sharper point on it: projects with clear requirements documented before development started were 97% more likely to succeed (Engprax / J.L. Partners, 2024). The IAG Consulting Business Analysis Benchmark measured the financial weight: one in three dollars of the application development budget is consumed by rework caused by poor requirements (IAG, 2009, n=437).

These are not marginal effects. They are the difference between a project that delivers and one that drains the budget before delivering anything useful.

This article is about the brief itself — the document you hand an agency before they write you a proposal. Not whether to build custom — we have covered that decision framework separately. Not what happens when quotes come back wildly apart — that is a different conversation. This is about what goes in, what gets left out, and why a ten-page document can be worth more than ten weeks of development.

I run a UK Laravel agency. I scope platform builds for a living. What follows is what I need from you to do that job properly — and what happens when I don't get it.

What I actually need from you — and what I almost never get

The complaints across the UK agency world are remarkably consistent. I hear the same four problems from every developer and project manager I speak to, and I hit them myself regularly.

No budget guidance is the universal frustration. When a brief arrives with no indication of investment range, I have to guess whether to propose the minimum viable version or the comprehensive solution. Whichever I guess, the other would have been right. Disclosing a budget range does not cap your project — it lets the agency propose appropriately. £20,000–£35,000 tells me something completely different from £60,000–£90,000. Both are valid. Neither is useful if I have to guess.

Describing a solution instead of a problem is the second pattern. "I need a dashboard with six charts showing sales data" gives me almost nothing to work with. "Our managers can't see daily sales performance without asking three different people and waiting until Tuesday" gives me everything. The first describes a screen. The second describes a problem with measurable business impact — and the best solution might not be a dashboard at all.

Treating every feature as Priority 1 is the third. If your list of requirements has everything marked as essential, you have not prioritised. You have made a list. Prioritisation means deciding what you would cut if you ran out of time or money — because on a long enough timeline, you will.

Briefs written by committee that contradict themselves is the fourth. Marketing wrote one section, IT wrote another, sales wrote a third. Each section is internally coherent but collectively they describe three different projects. I can either build all three (over budget), pick one (and disappoint two stakeholders), or ask for clarification — which adds weeks before a single line of code is written.

These are not edge cases. They are the norm. And every one of them produces the same outcome: a proposal built on assumptions, because the brief did not answer the question.

The ten sections that matter

Five major frameworks — IEEE 830, ISO/IEC/IEEE 29148:2018, the BABOK Guide v3, PRINCE2, and the GOV.UK Service Standard — all define what a requirements document should contain. They use different terminology, but the same core emerges when you map them against each other. These are the sections that appear across international standards, that UK agencies consistently ask for, and that the GOV.UK Service Standard mandates for public-sector work.

I have distilled them into ten. Every section below explains what it is, why it matters, and what goes wrong at week eight if you leave it out.

1. Purpose and business reason

Why this project exists. Not what you want built — why the business needs it. "We need a new website because the current one is outdated" is a feeling, not a business reason. It gives me no way to evaluate whether my proposal solves the actual problem. A sentence or two describing the problem, the opportunity, or the constraint that triggered the project is enough.

2. Scope — in and out

An explicit statement of boundaries. Not just what the project includes, but what it deliberately excludes. "Phase 1 includes the client portal and booking system. It does not include the reporting dashboard, the mobile app, or integration with the warehouse system — those are Phase 2."

Without explicit boundaries, you join the majority. PMI's 2018 Pulse of the Profession found 52% of projects experience scope creep — up from 43% five years earlier.

3. Users and stakeholders

Who will use the system, what they need from it, and how technically capable they are. The GOV.UK Service Standard mandates user-need statements: "As a [user], I need to [do something], so that [outcome]." You don't have to use that exact format, but you need to answer those three questions for every distinct user type.

"Our users are businesses" tells me nothing about whether we are building for three internal staff or three thousand external customers. Those are two different architectures.

4. Functional requirements

What the system must do — specific enough to build and to test. "Users can upload documents in PDF and DOCX format, up to 25MB per file, with a maximum of 10 files per submission" is a requirement. "Users can upload documents" is a wish.

Barry Boehm's original research found that a defect discovered in production costs roughly 100× more to fix than one caught at requirements stage for large systems, and around 5× for smaller ones (Boehm, Software Engineering Economics, 1981).

5. Non-functional requirements

This is the section almost every brief omits. It is important enough to get its own heading below.

6. Integrations and external systems

Every system your new platform needs to talk to. For each: what data flows, in which direction, how often. "It needs to integrate with our CRM" is not enough. Which CRM? Which edition? What data? Push or pull? Real-time or batched? Every unanswered question becomes an assumption — and assumptions are free until they are wrong.

7. Constraints and assumptions

Technical and business limitations: hosting restrictions, regulatory requirements, data residency rules, browser support, internal IT policies. If I assume a clean-sheet build and you discover at week six that the platform must run on an internal server with no internet access, we are both in trouble.

8. Budget range

A realistic indication of what you are prepared to invest. Not a ceiling — a range that lets me propose appropriately. "We'll assess proposals on value, not price" means "we want the cheapest option but don't want to say so." Be direct. It saves everyone's time.

9. Timeline and milestones

When the project needs to launch, whether that date is hard (regulatory deadline, funding milestone, contract expiry) or flexible, and any intermediate milestones that matter. "ASAP" is not a timeline.

10. Acceptance criteria and prioritisation

How you will decide whether the project is complete. Measurable conditions that define "done." Paired with MoSCoW prioritisation — Must-Have, Should-Have, Could-Have, Won't-Have — which forces you to decide what gets cut when reality diverges from the plan.

MoSCoW originated at Oracle UK in 1994 and is now formalised in the Agile Business Consortium's project framework. The rule of thumb: Must-Have requirements should not exceed 60% of effort. The remaining 40% provides contingency. Without it, the project ends when the money runs out, not when the objectives are met.

We use MoSCoW in every Platform Discovery Sprint we run. It is one of the most effective tools for protecting a client's budget — and it costs nothing to apply.

The section everyone skips — non-functional requirements

Functional requirements describe what the system does. Non-functional requirements describe how well it does it — performance, security, accessibility, reliability, scalability, maintainability.

The international standard for classifying them — ISO/IEC 25010 — defines eight product quality characteristics. In practice, most briefs I receive mention none of them. The industry pattern bears this out: researchers surveying software architects found that non-functional requirements are often not documented, and when documented, the documentation is usually imprecise and rarely maintained (Ameller et al., 2012). A separate study of 118 agile practitioners confirmed that none of the thirty-plus canonical agile requirements practices explicitly mentions non-functional requirements (Kopczyńska et al., 2019).

The consequences are well-documented. When the US launched Healthcare.gov in 2013, the Government Accountability Office found it was deployed without verification that it met performance requirements (GAO-15-238, 2015). Registration took 71 seconds. The site handled roughly 35,000 concurrent users — a fraction of demand. Federal costs rose from $56 million to $209 million in thirty months. In the UK, the NAO's assessment of Universal Credit concluded that the source of many problems was the absence of a detailed view of how the system was meant to work, with security and integration requirements left unspecified (NAO HC 621, 2013).

The brief is where you prevent this. Three categories matter most.

Performance

If the brief says nothing about load time, the developer builds to whatever their local machine delivers. That is not what your users experience on a 4G connection in rural Lincolnshire.

The benchmarks are established: a 100-millisecond delay reduces conversion by 7%, a two-second delay increases bounce rates by 103%, and 53% of mobile visitors abandon pages taking longer than three seconds (Akamai, State of Online Retail Performance, 2017). Google's Core Web Vitals set concrete thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Put those numbers in the brief.

Security

At minimum: HTTPS enforced, data encrypted at rest and in transit, role-based access control, patching policy documented. If the platform handles personal data — and under UK GDPR, most do — the brief should reference the lawful basis for processing and data retention periods. We have written about what happens when security is left to the developer's judgement — particularly with AI-generated codebases.

Accessibility — the legal requirement nobody briefs for

The European Accessibility Act came into force on 28 June 2025 with extraterritorial reach. UK businesses are in scope if they serve EU consumers — e-commerce, SaaS, banking, transport, e-communications. Microenterprises (under 10 staff, under €2 million turnover) are exempt for services. Existing services have until 28 June 2030 to comply. Penalties vary by member state — Ireland includes criminal liability with fines up to €60,000 and imprisonment up to 18 months (S.I. No. 636/2023).

For UK public-sector work, the Public Sector Bodies Accessibility Regulations 2018 apply. GDS began monitoring against WCAG 2.2 AA from October 2024. The Equality Act 2010 applies to private and public sectors — WCAG 2.2 AA is the most defensible way to evidence the duty to make reasonable adjustments.

The scale of the gap: the WebAIM Million automated scan of the top one million home pages found 95.9% had at least one detectable WCAG 2 failure (WebAIM, 2026). An average of 50+ errors per page.

For your brief: specify WCAG 2.2 AA as a non-functional requirement. If you serve EU consumers, reference EN 301 549. If you serve UK public-sector clients — as we do with NHS trusts and universities — specify PSBAR 2018. If the brief does not mention accessibility, the developer will treat it as optional. After June 2025, it is not.

How long should the brief be

The industry consensus lands on a ceiling of roughly ten pages. Several practitioners recommend as few as two. A brief does not need to be comprehensive to be effective — it needs to be clear.

The right length depends on project complexity. A useful rule of thumb:

Under £20,000 — two to four pages. Company overview, the problem, users, a prioritised feature list, budget range, timeline. Enough for an informed discovery conversation.

£20,000–£100,000 — five to ten pages. Add detailed functional and non-functional requirements, integration descriptions, constraints, acceptance criteria, and evaluation criteria for comparing proposals. MoSCoW prioritisation is essential here — without it, you will receive proposals that are impossible to compare because each agency assumed different scope.

Over £100,000 — fifteen-plus pages. A formal Software Requirements Specification aligned with ISO/IEC/IEEE 29148:2018. Individual requirements with unique identifiers, traceability, verification approach. UK government procurements on G-Cloud operate at this level.

Most UK SME platform builds — the £25,000–£75,000 range — sit in the middle tier. If you are reading this article, that is probably your project.

What a good brief earns you

A properly written brief earns three things. Comparable quotes — because every agency is pricing the same scope, not their own interpretation of it. Fewer change orders — because requirements were explicit before development started. And a shared definition of success — because acceptance criteria exist before the first line of code.

The IAG benchmark found that companies with strong requirements practices spent $2.24 million less per project than those with poor practices, on projects averaging $3 million (IAG, 2008, n=110). Scale that down to a £50,000 UK platform build and the principle holds: the brief is the highest-leverage document in the entire project.

But there is an honest alternative worth acknowledging. Writing a strong brief requires time, clarity, and enough technical literacy to specify non-functional requirements credibly. Not every founder has that — and there is no shame in it. Most of my clients are non-technical. They know their business inside out but would not naturally produce a document with MoSCoW prioritisation and ISO 25010 quality attributes.

That is precisely why we built the Platform Discovery Sprint.

The brief you don't write

The BCS found that only one in eight EU IT projects could be considered truly successful (McManus & Wood-Harper, 2008, n=214). Flyvbjerg's research at Oxford studied 5,392 IT projects and found average cost overruns of 27%, with one in six experiencing overruns above 200% (Flyvbjerg & Budzier, Journal of Management Information Systems, 2022).

The brief is the single most effective intervention against those odds. If you write one with explicit scope, measurable non-functional requirements, MoSCoW prioritisation, and acceptance criteria — you have done more to protect your investment than any contract clause or methodology can.

If writing that document is beyond what you can produce on your own — because you are a founder running a business, not a business analyst — the honest answer is to pay someone to do it properly. That is what scoping exists for. The cost of a structured discovery is a fraction of what it costs to find the gaps at week eight of a build.

The most expensive brief is the one that never gets written.