How to Brief a Web Agency When You're the Only Technical Person in the Room
Key takeaways
- A specific brief protects you; a vague one only protects the agency.
- Every decision left out of the brief gets made later, under pressure, by the wrong people.
- Brief your organisational context and governance, not just visual preferences and features.
- Write requirements as user stories that name who benefits and the quality standard.
- Specify often-omitted non-functional needs: performance, accessibility, ownership, documentation and training.
- Confirm IP ownership, deliverable-linked payments, change control and post-launch support before signing.
Summary
Being the only digital person at a nonprofit is a specific kind of professional exposure. When the website project goes wrong — and it goes wrong more often than organisations acknowledge — the Communications Director or Digital Manager is the one who briefed the agency, signed off the deliverables, and accepted the handover. If the brief was unclear, the accountability is theirs. If the agency misunderstood the stakeholder requirements, the accountability is still theirs.The failures that most commonly result from poor briefing are predictable: a site that serves the agency's portfolio aesthetic rather than the organisation's stakeholder needs, accessibility compliance that was not specified so was not delivered, a CMS architecture that the developer understood and the communications team cannot use, and a handover that leaves the organisation with a site nobody internally knows how to maintain.This post covers how to write a nonprofit web brief that prevents these failures. It addresses how to specify stakeholder requirements rather than design preferences, how to write WCAG compliance into the brief as a non-negotiable deliverable with a testing standard rather than a vague aspiration, how to specify CMS architecture requirements from the perspective of the editorial team rather than the developer, what to require from the agency at handover, and how to document governance requirements so clearly that misunderstandings become contractually consequential.
You understand enough to know what the organisation needs from its website. You understand enough to evaluate proposals when they come in. But you’re not a developer, you’re not a designer, and when the agency starts talking about headless architecture and API integrations, the power balance in the room shifts and decisions get made that you’ll be managing the consequences of for the next three years. This doesn’t have to happen.
The Brief Is Protective, Not Just Descriptive
A web agency brief is not just a description of what you want. It’s a document that defines what the agency is accountable for delivering, what success looks like, and what happens when expectations aren’t met. A vague brief protects the agency. A specific brief protects you.
Every decision that isn’t made in the brief gets made later — under time pressure, without the organisational context that informed the original intention, and often by the wrong people. The more specific the brief, the more control you retain over outcomes.
What the Brief Must Cover
Organisational Context, Not Just Website Requirements
Agencies that understand your governance context, your audience complexity, and your operational constraints make better decisions than agencies that understand your visual preferences. Brief the organisation as thoroughly as you brief the website. Include: how many people are responsible for content, what their technical comfort level is, what the approval process looks like, what happens to the site when you’re not available.
User Research You Already Have
If you have data on how different audiences currently use the site — what they search for, where they exit, what they email you about that the website should answer — include it. This is more valuable to a competent agency than a mood board.
Functional Requirements as User Stories
Describe requirements as user stories rather than feature lists. “Our comms coordinator needs to publish a new blog post in under ten minutes without contacting a developer” is more useful than “we need a blog.” User stories make it explicit who benefits, what they need to do, and what the quality standard is.
Non-Functional Requirements That Are Often Omitted
The requirements that get missed are often the most operationally significant: performance standards (page load time), accessibility standards (WCAG level), device support (which browsers and devices must be tested), hosting and infrastructure ownership (who holds the credentials), documentation requirements (what needs to be delivered at project close), and training requirements (who gets trained on what, in what format).
Questions That Reveal Whether an Agency Is Right for a Nonprofit
Question • What a Good Answer Looks Like
Have you worked with organisations that have multiple stakeholder audiences? • Specific examples with named organisations and described challenges
How do you handle CMS training for non-technical teams? • Documented process: recorded video, written guide, live session, follow-up support
Who owns the site on day one after launch? • Unambiguous: all credentials, files, and assets transfer to the organisation
What’s your process when something breaks after launch? • Defined SLA with response times and escalation paths
How do you approach accessibility? • Integrated from design, not audited at the end
What does the handover package include? • Specific list of deliverables: documentation, source files, credentials, recorded training
What happens if we need to change agencies mid-project? • Clear process; no lock-in; assets transfer regardless of project status
Evaluating Proposals When You’re Not a Developer
When proposals come back, the things that look impressive to a non-technical evaluator — elaborate design concepts, technology stack names, portfolio screenshots — are not the most important things. What matters most: does the proposal demonstrate that the agency understood your brief? Does it describe a process, not just an output? Does it specify what you’ll receive at project close, not just what the site will look like at launch? Does the timeline include explicit milestones with defined deliverables?
The agency that responds to your brief about governance, team independence, and operational sustainability with a proposal that leads with visual concepts has not read the brief. That tells you something important about how the project will go.
The Contract Points That Digital Managers Regularly Miss
Before signing: confirm intellectual property ownership is explicitly assigned to your organisation. Confirm the payment schedule is tied to deliverable acceptance, not calendar dates. Confirm there is a defined process for changes to scope (a change control process, not just “we’ll discuss it”). Confirm what the post-launch support period covers and for how long.
For related guidance, see Evaluating a web consultant.
Further Reading
- Nonprofit Website RFP: How to Select Governance-Ready Consultants
- Website Handover Planning: What Operations Directors Need Before a Rebuild
- How to Build a Nonprofit Website Your Team Can Actually Maintain
- CMS Architecture for Nonprofit Content Teams: What Good Looks Like
What a Well-Briefed Project Delivers
Digital managers who’ve been through a well-specified project versus a poorly specified one describe the difference clearly: in a well-specified project, the agency delivers what was agreed, disputes are rare because expectations were written down, and the handover happens cleanly because handover was in the brief. In a poorly specified project, scope creep is constant, the budget runs over because the brief was vague, and the handover is incomplete because it was never specified at all.
You don’t need to be a developer to write a brief that protects the organisation. You need to be specific about what the organisation needs, rigorous about what good delivery looks like, and clear about what the agency is accountable for producing. That’s not a technical skill. It’s a management skill — and it’s the one that determines whether the project delivers what the organisation paid for.
Frequently asked questions
Write from requirements, not solutions. The brief should describe what the website needs to achieve for each stakeholder group, the technical standards it must meet (accessibility, performance, GDPR compliance), the governance requirements (who manages it, what CMS capability is needed), the content it must contain, and what success looks like 12 months post-launch. You don’t need to specify how the agency should build it — you need to specify what it must do. Technical prescriptions from non-technical clients often constrain agencies in ways that produce worse outcomes.
Include: organisational background and strategic context, primary stakeholder groups and their website needs, the specific problems the current website has, technical requirements (platform preferences if any, accessibility standard, performance targets, integrations required), content requirements and governance model, budget range, timeline, and what a successful handover looks like. Include what you don’t know as well as what you do — acknowledging gaps invites agencies to respond with recommendations rather than assumptions.
Evaluate on: understanding of the brief (did they address your specific requirements or present a generic response), relevant experience (nonprofit clients, not just portfolio aesthetics), governance approach (how do they plan to deliver a site the internal team can manage), process clarity (what happens when and how decisions are made), and total cost including post-launch support, training, and documentation. The lowest-cost proposal is rarely the lowest total cost once ongoing dependencies are accounted for.
Key questions: Can I speak to a nonprofit client you’ve worked with for more than two years post-launch? What does your handover documentation include? What can my non-technical team manage independently after training? What is your accessibility testing process? How do you handle scope changes? What are your standard response times for support? What happens if a key person on your team leaves during the project? These questions reveal how the agency thinks about maintainability, governance, and risk — not just about building websites.
Your technical knowledge is an advantage in this relationship — you can evaluate what’s being built and identify problems before they become expensive. Use it: review every milestone delivery against the agreed specifications, test accessibility and performance at each stage rather than only at launch, escalate concerns in writing so there’s a record, and don’t accept ‘trust us, it works’ for anything you can test yourself. The agency knows more about web development; you know more about your organisation’s needs. Both perspectives are necessary.
Specify: WCAG 2.2 AA accessibility compliance with testing methodology defined, Core Web Vitals targets (LCP under 2.5s, CLS under 0.1, INP under 200ms), GDPR compliance including cookie consent implementation and data processing agreements, HTTPS with valid SSL, clean URL structure without parameters, structured data markup for relevant content types, and mobile-first design. These should be acceptance criteria for the project, not aspirational targets — the site should not be accepted until it meets them.
Create a stakeholder map before writing the brief: for each primary stakeholder group, document who they are, what they need from the website, what their typical journey looks like (where they arrive, what they need to find, what action they should take), and what success looks like for that group. Include this in the brief as user stories or journey maps. Agencies that receive this level of stakeholder detail produce more relevant architecture than those given a vague ‘we need a website that serves donors and beneficiaries’.
A complete rebuild with a good agency takes 16-24 weeks from project start to launch. Brief development and procurement takes four to six weeks before the project starts. Allow 28-30 weeks total from starting the brief to launch. Agencies that promise delivery in eight to twelve weeks for a complex nonprofit site are either underestimating the work or planning to cut corners on testing, training, and documentation. Tight timelines consistently produce poor handovers and governance failures.
First, identify which elements of the specification are driving the cost — a good agency will break down the proposal by workstream. Then assess which elements are essential (accessibility compliance, core stakeholder journeys, proper handover) versus desirable (advanced features, content creation, complex integrations). Negotiate scope rather than price — reducing scope while maintaining quality standards produces a better outcome than reducing price while maintaining scope at the cost of quality. If the essential elements can’t be delivered within budget, the budget rather than the scope needs to change.
Build knowledge transfer into the contract: require that documentation is produced throughout the project (not assembled at handover), specify that training is included in scope, require that all credentials are transferred before final payment, and negotiate a post-launch support period where the agency is available for questions. During the project, ask agencies to explain technical decisions rather than just implement them — your understanding of why things were built the way they were is part of the institutional knowledge the organisation needs.
