How Nonprofit Digital Managers Should Brief a Web Agency

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

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.

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.

Q1: How do you write a brief for a web agency as the only technical person in a nonprofit?

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.

Q2: What should a nonprofit digital manager include in a web agency brief?

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.

Q3: How does a solo digital manager evaluate web agency proposals?

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.

Q4: What questions should a digital manager ask a web agency before hiring them?

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.

Q5: How do you manage a web agency when you're the only technical person at the nonprofit?

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.

Q6: What technical standards should a digital manager specify in a web agency brief?

Specify: WCAG 2.1 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.

Q7: How do you brief a web agency on a nonprofit's complex stakeholder requirements?

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'.

Q8: What is a reasonable timeline for a nonprofit web agency project?

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.

Q9: What should a digital manager do if an agency's proposal exceeds the budget?

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.

Q10: How do you ensure knowledge transfer when working with a web agency as the only technical person?

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.