The most common reason nonprofit website projects go wrong isn't the build. It's what happens before the build — or more accurately, what doesn't happen.

A brief gets written based on assumptions about what stakeholders want. Those assumptions turn out to be wrong. The project either stalls while everyone realigns, or it delivers something technically correct but strategically misaligned. Either outcome wastes the organisation's money and trust.

This guide covers how to manage a nonprofit website project from initial decision through to launch: the process, the roles, the decisions, and the places where things typically go wrong.

Phase 1: Decision and Scoping

Start With Why

Before any technical work begins, the organisation needs to be clear on why a new or redesigned website is the right intervention at this time. The answer shouldn't be "because ours looks old" — that's a symptom, not a strategy.

Questions to answer at this stage:

• What specific problems is the current website causing for the organisation?
• Which stakeholders are affected by those problems?
• What would success look like in 12 months?
• Why now, rather than 6 months ago or 6 months from now?

If these questions are hard to answer, the project isn't ready to move forward. Proceeding without clear answers produces a brief that no agency or consultant can confidently execute.

Identify the Decision-Makers

Nonprofit website projects involve multiple stakeholders with different interests. Before any brief is written, establish:

• Who has final approval authority on the completed site?
• Who needs to be consulted at which stages?
• Who manages the day-to-day relationship with the agency or consultant?
• Who owns the project internally, and what authority do they have to make decisions without escalation?

Ambiguity on these questions — particularly on approval authority — is a direct cause of project delays. A project manager who can't approve copy without three committee sign-offs will struggle to maintain any delivery timeline.

Initial Scoping

Once the why is clear and decision-makers are identified, develop an initial scope:

• Which pages and sections need to be redesigned or built from scratch?
• Which content can be reused from the current site, and which needs to be created?
• What functionality is needed beyond standard pages (forms, CMS, multilingual, member areas)?
• What are the technical constraints (hosting requirements, existing tools that need to integrate)?
• What is the budget range, and who has approved it?

At this stage, scope is intentionally approximate. The purpose is to establish whether the project is viable and to have an informed conversation with potential agencies or consultants.

Phase 2: Agency or Consultant Selection

What to Look for Beyond Portfolios

Portfolio quality matters, but it's not sufficient for selecting a nonprofit website partner. Look also for:

• Sector experience: Have they worked with organisations similar to yours? Do they understand funding accountability, Board oversight, and multi-stakeholder communication? A generalist agency with no sector experience will learn on your project.
• Process clarity: Can they explain how decisions get made during the project? How do they handle scope changes? What does their handover process look like?
• Governance alignment: Will they deliver a site that your team can actually maintain? Or will you need to call them every time you want to update a photograph?
• Reference conversations: Ask to speak with a recent client. Specifically ask about what went wrong and how it was handled — not just what went well.

The Brief

A good brief is the most important document in a website project. It should cover:

• Organisation overview and strategic context
• Primary audience and what they need from the site
• Specific goals and success metrics
• Functional requirements
• Content overview
• Technical requirements and constraints
• Budget range
• Timeline requirements and key dates
• Approval and decision-making process

The brief shouldn't specify solutions — that's the agency's job. It should specify the problem the site needs to solve and the constraints within which the solution must operate.

Phase 3: Discovery and Strategy

Why Discovery Is Non-Negotiable

Discovery is the phase where you and the agency establish shared understanding of the project before any design or build work begins. For nonprofits, this typically involves:

• Stakeholder interviews or workshops
• Review of existing site analytics
• Content audit of the current site
• User research (varying levels of formality depending on budget)
• Competitor and sector benchmarking

Organisations that skip discovery — or treat it as a box-ticking exercise — find that fundamental strategic questions surface mid-build, when they're expensive to address. The Blueprint Audit I offer is essentially a structured discovery process: it establishes what's actually needed before any build work begins.

Sitemap and Content Strategy

Discovery outputs typically include a proposed sitemap — the structure of the new site — and a content strategy that identifies what needs to be created, edited, or retired.

This is a decision point that requires explicit stakeholder approval. A sitemap isn't a technical document — it's a strategic document about how your organisation presents itself. It should be reviewed and approved by whoever has authority over organisational communications.

Phase 4: Design

The Design Review Process

Design review is one of the highest-risk stages in a nonprofit website project. Without clear process, it produces cycles of subjective feedback, stakeholder disagreements, and scope creep.

Effective design review requires:

• Clear review criteria (does this meet the agreed brief? does this work for our primary audience?) rather than aesthetic preference
• Consolidated feedback from a single point of contact, not multiple stakeholders providing contradictory directions
• A defined number of revision rounds included in scope, with a clear process for additional rounds
• Board or senior leadership review at an appropriate checkpoint (not on every iteration)

Mobile-First Review

Review designs on mobile as well as desktop. Most nonprofit website visitors arrive on mobile devices. A design that works beautifully on a laptop and inadequately on a phone is a design problem, not a mobile problem.

Phase 5: Build

Managing Content During Build

The most common cause of build-phase delays isn't technical problems. It's content. Specifically: content that hasn't been written, approved, or provided to the agency when they need it.

Establish a content delivery schedule at the start of the build phase. Know which pages need content when, and who internally is responsible for delivering it. Build in review time before delivery — content that arrives the day it's needed creates bottlenecks.

Staged Review vs. End-of-Build Review

Reviewing the site in sections during build (section by section or page by page as they're completed) distributes the review workload and catches problems earlier. End-of-build review produces a compressed, high-pressure feedback period that's prone to missing issues.

Accessibility Throughout

Accessibility isn't a final check — it's a build principle. Structure, heading hierarchy, colour contrast, keyboard navigation, and form labelling need to be correct during build, not retrofitted afterwards. WCAG AA compliance should be a named requirement in the project brief and verified progressively during build.

For what WCAG AA requires, see my guide on WCAG AA compliance for nonprofit websites.

Phase 6: Testing and Launch Preparation

See the nonprofit website pre-launch checklist for the complete list of what needs to happen before a site goes live.

The project management perspective on this phase: testing takes longer than people expect. Build in a minimum of two weeks for systematic testing, error correction, and re-testing. Compressed testing periods produce launches that discover problems live rather than in staging.

Phase 7: Handover and Post-Launch

What Good Handover Looks Like

At project end, your organisation should have:

• Full ownership of the Webflow workspace and site (not access via the agency's account)
• Documentation of how to update the site — not a generic Webflow tutorial, but documentation specific to your site's structure and conventions
• A trained team member who can make routine content updates without external support
• A clear agreement on what post-launch support looks like and how to access it

The Post-Launch Period

Expect to discover issues in the first 2–4 weeks after launch. This is normal. What matters is having a clear process for reporting and resolving them, and a partner who treats post-launch issues as their responsibility to fix rather than as out-of-scope extras.

Ongoing Governance

Launch is not the end of the project. A website that isn't maintained degrades. Content becomes outdated. Technical issues accumulate. Governance responsibilities need to be established at handover and owned internally.

For establishing ongoing governance, see my guides on website governance policies and website performance monitoring.

Common Project Failure Points

Based on the projects I've audited after they've gone wrong, the most consistent failure points are:

Unclear approval authority: Projects stall when no one knows who can actually say yes. Establish this before any work begins.

Late content: Content is the most common cause of build delays. Treat content delivery as a project management responsibility, not an afterthought.

Scope creep during build: New requirements that weren't in the original scope add time and cost. Have a clear process for evaluating and approving scope changes, including their cost and timeline impact.

Compressed testing: Testing gets shortened when the rest of the project runs late. The result is launches with undetected problems. Protect the testing phase.

Unclear handover: Projects that end without explicit handover leave organisations without ownership of their site or the knowledge to maintain it.

The Blueprint Audit — which I run before any build work — is specifically designed to identify and resolve these failure conditions before a project starts rather than after it ends. If you're planning a website project, that's the right starting point: Blueprint Audit.