The RFP process is the default way nonprofits hire website help. It is also, for most organisations, a spectacular waste of time.

Here is what typically happens. The Board or senior leadership agrees the website needs work. The Communications Director is asked to manage the procurement. They spend weeks writing a document that attempts to define technical requirements they are not qualified to define, circulate it to agencies and freelancers, receive proposals that are impossible to compare because every respondent has proposed a different scope, and then choose based on price, presentation quality, or gut feeling. The whole process takes months before any actual work begins.

The fundamental problem is that an RFP assumes you already know what you need. For most nonprofits, that is precisely the thing you do not know. What you know is that the website is not working. You do not know whether it needs a rebuild or targeted fixes, which stakeholders the architecture should prioritise, what accessibility obligations you are failing to meet, or where the actual gaps between what the site does and what the organisation needs are.

There is a better way to evaluate web consultants: one that starts with understanding the problem before defining the solution.

Why RFPs Fail Nonprofits Specifically

RFPs were designed for procurement contexts where the buyer can specify exactly what they need: a quantity of materials, a defined service with measurable outputs, a product with known specifications. Websites do not work this way. Two consultants can look at the same brief and propose fundamentally different solutions, both of which might be appropriate. The RFP format makes it impossible to evaluate which approach is better because it treats the proposals as comparable when they are not.

For nonprofits, the problem is compounded by several factors.

The person writing the RFP is rarely a technical specialist. Communications Directors are skilled at messaging, campaigns, and stakeholder management. They are not typically web architects or accessibility specialists. An RFP written without deep technical knowledge tends to either under-specify (leaving respondents guessing) or over-specify based on assumptions that may be wrong.

The best consultants often do not respond to RFPs. Experienced independent consultants and specialist agencies know that RFP processes favour the cheapest bid or the most polished presentation, neither of which correlates with project success. Many will not invest the time required to respond to a formal RFP, which means the process systematically excludes some of the people most qualified to do the work.

Price comparison is misleading. A fixed-price proposal for a rebuild and a Monthly Partnership cover fundamentally different models. The RFP format forces you to compare them as if they are the same thing. They are not. One is a fixed deliverable with a defined end point. The other is ongoing capacity with iterative improvement. The right choice depends on your organisation’s situation, not on which number is smaller.

The timeline is punishing. Months of procurement are months where the website’s problems continue to affect your credibility with funders, your accessibility compliance exposure, your team’s capacity, and your stakeholders’ experience. For organisations facing Board scrutiny, regulatory pressure, or an upcoming funding cycle, that delay has real institutional cost.

What to Evaluate Instead

If you set aside the RFP format, the question becomes: how do you evaluate whether a web consultant is the right fit for your organisation? Here are the criteria that actually predict project success for nonprofits.

Do they specialise in your sector? Nonprofit websites fail in ways that generic web consultancy does not address: governance documents that funders expect to find, accessibility obligations under the Equality Act 2010, which puts a duty to make reasonable adjustments on service providers, and increasingly the European Accessibility Act, which has applied to in-scope services provided to consumers in the EU since 28 June 2025, content workflows designed for teams where one person manages everything, stakeholder journeys that serve donors, beneficiaries, regulators, and the Board simultaneously. A consultant who primarily works with e-commerce or corporate clients may build a beautiful site that misses these requirements entirely.

Do they start with diagnosis or design? If the first thing a consultant proposes is a design concept or a sitemap, they are skipping the most important step. The right first step is understanding your organisation: who your stakeholders are, what they need from the site, where the current site fails them, and what governance obligations apply. A consultant who begins with a diagnostic is one who will recommend what you actually need rather than what generates the most revenue for them.

Will they tell you if you do not need a rebuild? This is the most important test of integrity. If a consultant’s business model depends on selling rebuilds, their recommendation will always be to rebuild. Ask directly: under what circumstances would you recommend targeted fixes rather than a full rebuild? If they cannot answer that question clearly, they are not evaluating your situation. They are selling a service.

Can they explain their approach in governance language? Your Board does not care about Webflow versus WordPress, or CSS frameworks, or CMS architecture. They care about institutional risk, stakeholder credibility, regulatory compliance, and return on investment. A consultant who can only explain their work in technical terms will leave you translating for your Board. A consultant who frames recommendations in governance language makes the decision-making process simpler for everyone.

What is their model for ongoing support? A website is not a project with a start and end date. It is infrastructure that requires ongoing maintenance, content updates, accessibility monitoring, and periodic improvement. Ask what happens after launch. If the answer is ‘we hand it over and you manage it’, assess honestly whether your team has the capacity and expertise to do that. If not, the ongoing support model matters as much as the initial build.

Do they own their recommendations? Independent consultants who do the work personally have a different accountability relationship from agencies where the person who sold the project is not the person who delivers it. Neither model is inherently better, but you should know who will actually be making decisions about your website and whether you will have direct access to that person.

The Alternative to an RFP: Start With a Diagnostic

Instead of spending months defining what you think you need and asking consultants to bid on it, start with a structured diagnostic that establishes what you actually need.

A diagnostic engagement does several things an RFP cannot. It interviews your stakeholders to understand what different audiences need from the site. It assesses the current site’s technical condition, accessibility compliance, and content accuracy. It maps your stakeholder landscape to identify which audiences should drive the architecture. And it produces a report that gives your Board the information they need to make an informed decision about what comes next.

The Blueprint Audit is how I do this. It is a standalone engagement, and the report belongs to the organisation: implement the recommendations internally, brief another provider using the findings, or return to them when the timing is right. That page sets out what it covers and what happens afterwards.

What If Your Board Requires an RFP?

Some boards have procurement policies that mandate competitive bidding above a certain threshold, sitting alongside the trustee duty to use reasonable care and skill and take appropriate advice. If that applies to your organisation, you can still improve the process significantly. Selecting consultants who understand governance covers how to write the RFP itself.

Keep the RFP focused on your organisation’s situation, not on technical specifications. Describe your stakeholders, your challenges, and what success looks like, not what CMS you want or how many pages you think you need. Let respondents propose their own approach rather than bidding on a predefined scope. Evaluate based on understanding of your sector, diagnostic methodology, and ongoing support model rather than on price alone.

For the governance context behind these decisions, see Why Your NGO Website Is a Governance Problem. For how stakeholder priorities should drive your website architecture, see Nonprofit Website Stakeholder Mapping. For the practical question of whether to fix or rebuild, see When to Rebuild vs. Fix Your Nonprofit Website.