If you work at a nonprofit and you're about to send out an RFP for a new website, I need to tell you something most guides won't: the RFP process is stacked against you. Not because the process itself is broken, but because the nonprofit world adds layers of complexity that most RFP advice completely ignores.
Board procurement rules. Committee decision-making. Grant-funded timelines. Budgets that make experienced vendors pass without reading past the first page. These are the realities of nonprofit website projects, and a generic RFP template won't help you deal with any of them.
I've been responding to nonprofit and association RFPs for over 25 years. FatLab manages roughly 200 WordPress websites, and a significant portion of our clients are 501(c)(3) organizations, professional associations, medical certification boards, and advocacy groups. We host and maintain these sites long-term, which means we see what happens well after the build is done and the original vendor has moved on.
Most of the time, the problems trace back to the RFP.
This guide covers what's different about the nonprofit website RFP process and how to structure yours so that quality vendors actually respond, your board is satisfied, and the project has a real chance of succeeding.
The "Three Bids" Problem
Let's start with the elephant in the room. Most nonprofits have bylaws or procurement policies that require competitive bids for purchases over a certain threshold. For website projects, that threshold is almost always triggered. Your board, your finance committee, or your funder expects to see at least three proposals before approving the spend.
In theory, this protects the organization. In practice, it often undermines the project before it starts.
Here's what I see happen constantly: an association or nonprofit has already identified who they want to work with. They have every intention of awarding the job to that vendor. But they still have to collect competing bids to satisfy their bylaws. So they send the RFP to two or three other vendors to check a box.
What happens next is, frankly, unethical, but it happens constantly. The organization collects all the bids, gathers up the good ideas, scope suggestions, and pricing, and hands everything to their preferred vendor, who then assembles a winning proposal using everyone else's work.
I've been on the receiving end of these. You submit your proposal, and almost as fast as you hit send, you get a note thanking you for your time, but they've decided to go a different direction. You can feel it. And after 25 years, I rarely choose to respond to a blind RFP from a nonprofit I have no connection with, because someone in the organization almost always already has a preferred vendor.
The result is that the best vendors are the most skeptical of your RFP. Responding is not a trivial investment. A quality vendor spends 25 or more hours preparing a thoughtful proposal, which, according to Responsive, represents $3,000 to $7,500 in unrecoverable costs. Vendors who have been burned become selective. If you want quality responses, you need to signal that your process is legitimate.
How to Run an Honest Competitive Process
If your procurement rules require competitive bids, respect the process enough to run it fairly. Here's what that looks like:
Be transparent about the field. Tell vendors how many firms are being invited to respond. Disclose whether there's an incumbent. If you have a preferred vendor, either sole-source the project (if your bylaws allow it at your budget level) or genuinely open the competition. There's no middle ground that doesn't waste people's time.
Set and share evaluation criteria before you receive proposals. Your committee should agree on what matters, with weights assigned, before any proposals arrive. Something like 30% technical approach, 25% relevant experience, 20% cost, 15% timeline, 10% ongoing support. This prevents post hoc rationalization, where the committee reverse-engineers a justification for whoever they already liked.
Commit to a decision timeline. "We will notify the selected vendor by [date]" creates accountability. Committees that take months to evaluate proposals burn vendor goodwill and often lose their best candidates.
Consider a pre-qualification round. Instead of asking five vendors for full proposals, issue a brief Request for Qualifications to eight or ten firms. Review credentials, portfolios, and references. Then invite three qualified firms to submit full proposals. This reduces wasted effort on all sides and produces a stronger final pool.
For a deeper look at building a fair, thorough evaluation process, see our guide to writing a website RFP that actually gets quality responses.
Budget Reality for Nonprofits
Since the dawn of the internet, there's been this idea that if it's online or open source, it should be free or cheap. Your website is a 24/7 window into your organization. Especially for nonprofits and associations that have membership portals, collect dues, or manage RSVPs for events, this is not the place you want to save money.
A website costing tens of thousands of dollars that manages your membership and serves as the primary touchpoint for your constituents? That's actually cheap when you consider the alternative. No human employee could deliver everything a well-built website delivers with that level of efficiency, and they would cost you far more. This is an investment in a critical communications channel.
The sticker shock is real. But in this industry, the gap between what you pay and what you get is enormous, and I've watched organizations learn that lesson the expensive way more times than I can count.
Why Nonprofit Budgets Are Consistently Lower
Several structural forces push nonprofit website budgets below what the project actually requires:
Board perception. Board members who run businesses may know their company spent $80,000 on a website but believe the nonprofit should spend $15,000 because "it's simpler." The complexity gap is often much smaller than they assume. The nonprofit site still needs a responsive design, content management, donation processing, event registration, and accessibility compliance. That's not a simple project.
Overhead ratio pressure. Websites get classified as administrative or overhead expenses. The persistent (and misguided) pressure to minimize overhead ratios directly suppresses technology investment. The "overhead myth," the idea that low overhead equals organizational effectiveness, is one of the most damaging forces in the nonprofit sector. It leads organizations to underinvest in exactly the infrastructure they need to deliver their mission.
Annual budgeting cycles. Most nonprofits budget annually. A website project that spans fiscal years creates accounting complexity. The result is projects scoped to fit within one fiscal year's budget allocation, even when the actual need exceeds that amount.
No revenue attribution. A commercial website can justify its cost through direct revenue generation. Nonprofit websites generate donations, volunteer sign-ups, and constituent engagement, but the attribution is harder to demonstrate. That makes the ROI argument weaker in board presentations, even when the website is clearly the organization's most important communications channel.
Template comparison shopping. Decision-makers compare custom development quotes against Squarespace or Wix pricing without understanding the differences in capabilities, ownership, and long-term costs. A $15/month Squarespace site and a $25,000 custom WordPress build are not even in the same category. The Squarespace site doesn't integrate with your CRM, doesn't give you ownership of your content architecture, and creates long-term platform dependency.
Realistic Budget Ranges
Based on what we see in the market:
- Small nonprofits (under $1M organizational budget): $5,000 to $15,000 for a solid WordPress site with a custom design, basic donation integration, and content migration. Many organizations in this range hope for $5,000 or less, which is possible but significantly limits the scope.
- Mid-size nonprofits ($1M to $5M budget): $15,000 to $50,000. Custom design, content strategy, donation platform integration, CRM connectivity, and program-specific features. The $20,000 to $35,000 range is where most projects in this tier land.
- Large nonprofits and associations ($5M+ budget): $50,000 to $150,000 or more. Custom development, member portals, event registration systems, complex integrations, accessibility compliance, and potentially multi-site architectures.
These numbers cover the build. They don't cover the ongoing costs that every nonprofit needs to budget for, but most don't. I'll address that later.
One more thing about budget: There is no regulatory body in our industry, and no standard pricing pattern for websites. Pricing can be wildly inconsistent. We recently reviewed a proposal for a nonprofit in Washington, DC, where the vendor quoted $150,000 for a site I would have built for a fraction of that. The client had no way of knowing they were being overcharged because they did not have a technical advisor reviewing the proposal.
Getting multiple bids at a stated budget range is one of the best protections against this.
Include Your Budget in the RFP
This is the single most important piece of advice in this guide, and I've written about it at length in our main RFP guide. When you don't provide a budget, you're forcing vendors to take shots in the dark. If you tell me what you can spend, I'll tell you what I can do for that. You'd be surprised: if the project is good, or I personally like the client, I might be willing to do a lot more for less. But I don't know any of that yet without a budget.
Nonprofits are especially reluctant to share budgets because they've been trained in competitive procurement thinking. The fear is that vendors will "anchor" to the high end of your range.
Budget transparency yields dramatically better proposals because every vendor operates under the same constraints. Your proposals become comparable. Without a budget, you get a shotgun blast of prices at wildly different scope levels, and your committee has to compare apples to oranges with no way to understand why one proposal costs five times more than another.
If you genuinely don't know what a reasonable budget is, say that. Declare that you're looking for guidance on what things cost. That's fair. But saying "let's see what you come up with" while secretly having a number in mind is not fair, and it will cost you access to the vendors who would serve you best.
Attracting Quality Vendors When Your Budget Is Low
This is the question every small nonprofit asks: how do we get good work when we can't pay market rate?
I'll give you the honest answer. If your budget is below market rate, the only way you're going to attract quality vendors is to be upfront about it. Skip the sugarcoating. Don't promise a great portfolio piece, don't promise that you'll tell all your members about us and they'll hire us, and don't tell us you're well-connected and can get us more jobs.
In 25 years of business, I have yet to be made or broken by such promises. I value them at zero dollars. It just doesn't happen.
What actually works:
Be the easy client. Clear scope, responsive communication, a decision-maker with authority, and content delivered on time. Vendors will sometimes work for less when the project is well-organized and the client is a genuine pleasure to work with. The inverse is also true: a difficult client on a low budget is the worst combination in our industry.
Phase the project. Instead of requesting everything at once, define a Phase 1 within your available budget and a Phase 2 as a future project when additional funding is secured. This makes the immediate project achievable and signals that you're thinking about a long-term relationship, not a one-time transaction.
Offer timeline flexibility. If you don't have a hard deadline, letting the vendor fit your project between larger engagements can reduce cost. You're filling gaps in their schedule, which means other projects already cover their overhead.
Be direct about your constraints. "We have $20,000 from a foundation grant. What can we achieve within that budget?" gets a much better response than a 15-page RFP requesting $100,000 worth of features with no budget mentioned. The first is a conversation starter. The second is a waste of everyone's time.
Look for vendors who care about your mission. Many web developers, especially those who specialize in the nonprofit sector, are genuinely motivated by mission-driven work. A compelling description of what your organization does and why the website matters to that mission has real value in an RFP. It won't close a $50,000 budget gap, but it can tip the scales when a vendor is deciding between your project and a better-paying one.
And if you do get a proposal that seems too good to be true, it probably is. A cheap proposal is often designed to win the project by quoting a low number without clearly defining what will be built. The theory is: win the client, then deal with scope later.
If your lowest bidder came in significantly below the others, go back and ask why. You will likely find that things were not included or the scope was not defined. You probably do not want your lowest bidder, and you probably do not want your highest bidder either. The middle is usually where the honest proposals live.
FatLab offers 20-40% discounts for 501(c)(3) organizations, and we're not the only firm that does this. But you have to ask. And you have to be honest about your situation. Playing games or sugarcoating things leads to the wrong kind of service provider, and it backfires for everyone.
The Committee Problem
Website projects in nonprofits rarely have a single decision-maker. You have the executive director who owns the budget, the communications director who's usually writing the RFP, the development director focused on donation functionality, program staff who each want their programs featured prominently, a board technology committee whose expertise may be enterprise IT rather than web development, and a treasurer watching the bottom line.
This structure creates predictable failure modes that your RFP should address head-on.
Scope Creep by Committee
Each stakeholder adds requirements that reflect their department's needs. Nobody has the authority to say no. The RFP grows to describe a $200,000 project on a $30,000 budget.
When this lands on a vendor's desk, it signals that the organization doesn't understand what it's buying. Quality vendors recognize this pattern and pass.
Before you send your RFP, have someone with authority reconcile the scope with the budget. If the wish list exceeds what you can pay for, prioritize. Separate the "must have for launch" features from the "Phase 2" features. This is hard organizational work, but it's your work, not your vendor's.
The Board Member's Nephew
A board member knows "someone who does websites" and advocates for that person regardless of qualifications. This is more common than any vendor wants to admit, and it derails legitimate procurement processes.
Here's a scenario I've seen more than once: a board member's nephew builds a site on Squarespace for $3,000 while two qualified agencies submit proposals at $25,000 and $30,000. The committee, not understanding why the prices are so different, gravitates toward the cheaper option. Eighteen months later, the organization is paying one of those agencies to rebuild the site because the original couldn't handle their CRM integration, donation processing, or accessibility requirements. The "savings" cost them double.
This is exactly why weighted evaluation criteria matter. Personal connections are fine as one factor, but they shouldn't override a structured evaluation.
Champion Departure
The internal champion for the website project is usually the communications director. If that person leaves during the RFP process, the project often stalls or restarts entirely. Nonprofit staff turnover runs 20 to 25 percent annually, so this is not a hypothetical risk.
Multiple stakeholders should understand the project goals and timeline so the process can survive a personnel change.
Evaluation Paralysis
Committees may take months to evaluate proposals. During that time, vendor availability changes, pricing expires, and project urgency dissipates.
Set a decision timeline in the RFP. Name it publicly. Hold yourself to it.
What Your RFP Should Do
Name a single decision-maker. Even if a committee evaluates, one person should have final authority. State this in the RFP. Vendors read this as a signal that the organization is serious and organized.
Limit the evaluation committee to three to five people. More than seven becomes unwieldy. Every additional evaluator adds time and reduces the likelihood of a clear decision.
Define the decision timeline. "We will notify the selected vendor by [specific date]" signals to vendors that you're committed to moving forward. Open-ended timelines tell vendors to expect delays.
Nonprofit-Specific Sections Your RFP Needs
Beyond the standard sections every website RFP should include, nonprofit projects have specific requirements that need to be addressed upfront.
Mission Context
This is not fluff. Your vendor needs to understand what success looks like for your organization, and for nonprofits, that's fundamentally different from what it is for a commercial site. Is success measured in volunteer sign-ups? Advocacy actions? Event registrations? Donations? Some combination that varies by program area?
Define your audience hierarchy. Most nonprofits serve multiple audiences: donors, beneficiaries, volunteers, media, policymakers, and peer organizations. The website must serve all of them, but not equally. Tell your vendor who comes first.
This single piece of information will shape the entire information architecture and prevent weeks of back-and-forth during the design process.
Donation Integration
Online giving is mission-critical for most nonprofits. Your RFP should specify:
- Whether you use an existing donation platform (Network for Good, Classy, Bloomerang, Give Lively, Stripe) that the website must integrate with, or whether you need a new solution.
- Whether you need recurring giving capability. Monthly donor programs are increasingly central to nonprofit revenue strategy.
- Whether you need campaign pages that can be created and modified quickly for time-limited fundraising.
- What customization do you need on donation forms: preset amounts, designation options, tribute giving, and employer matching prompts.
Don't just write "must accept online donations." That could mean a PayPal button or a fully integrated giving platform with CRM sync. The gap between those two is $5,000 to $30,000 in development cost.
Accessibility
Nonprofits face heightened accessibility expectations. If you receive federal funding, Section 508 compliance is legally required. Many state and local funding sources also require WCAG 2.1 AA compliance. Even without government funding, the ADA applies to places of public accommodation, and courts have increasingly extended this to websites.
Beyond legal requirements, organizations serving vulnerable populations face reputational risk if their own websites are inaccessible. Major foundations are also increasingly asking about digital accessibility in grant applications.
Your RFP should specify the target WCAG conformance level (typically 2.1 AA) and require vendors to describe their accessibility testing methodology. Don't accept "we build accessible websites" at face value. Ask how they test and what tools they use.
CRM Integration
Most nonprofits maintain a constituent database or CRM, and the website-CRM relationship is a frequent source of scope creep and budget overruns.
The integration trap works like this: the RFP requests "full CRM integration" without anyone on the committee understanding what that actually entails or how much it costs. A bidirectional Salesforce-WordPress sync can easily run $15,000 to $30,000 in development alone, which could be half the total website budget.
Your RFP should specify:
- Which CRM do you use
- What data flows in which direction
- Which events trigger syncs
- What is the fallback when the integration fails
If you use Salesforce NPSP, Bloomerang, Little Green Light, DonorPerfect, NeonCRM, or another platform, name it. Let vendors assess the integration complexity before they quote.
And here's something most guides won't tell you: in many cases, a simple embed of your donation platform's hosted form accomplishes 80% of what organizations mean by "integration" at a fraction of the cost. Don't over-specify technical requirements. Describe what you need users to be able to do, and let the vendor propose the most efficient technical approach.
Grant-Funded Projects: What Changes
When a grant funds a website project, the procurement requirements become more rigid and the timeline constraints more punishing.
Procurement Requirements
Federal grants under the Uniform Guidance (2 CFR 200) require competitive procurement for purchases over the micro-purchase threshold ($10,000). The nonprofit must document the rationale for the procurement method, conduct a cost or price analysis, and maintain records of the evaluation process. Sole-source is permitted only under narrow circumstances.
Foundation grants vary, but most require the nonprofit to follow its own procurement policies. Some foundations require pre-approval of vendors or expenditures over a threshold.
State and local government grants often impose the most restrictive requirements, sometimes requiring a public posting period and a formal evaluation and scoring process.
The practical impact: the timeline between "we got the grant" and "we can hire a vendor" can be two to four months purely due to the procurement process. If your grant period is 12 months, you may have only eight to ten months for the actual project after procurement and board approval.
Timeline Awareness
Your RFP should tell vendors about the grant context:
- What is the grant period?
- When must the project be substantially complete?
- Are there interim reporting deadlines that require demonstrable progress?
- Will the vendor need to provide documentation formatted for the funder (deliverable sign-offs, progress reports, invoices broken into specific cost categories)?
Most funders allow one no-cost extension, typically three to six months, but requesting one signals poor project management and may affect future funding decisions. Plan the timeline to deliver within the original grant period.
This information helps vendors assess whether they can realistically deliver within your constraints. A vendor who understands grant timelines is far more valuable than one who doesn't realize the deadline is immovable.
Ongoing Costs After the Grant
Here's the trap most grant-funded website projects fall into: the grant pays for the build, but nobody budgets for what happens after launch. Hosting, maintenance, security updates, content management, plugin licensing. These ongoing costs are real, and they typically run $3,000 to $10,000 per year for a well-maintained nonprofit WordPress site.
If your grant doesn't cover ongoing costs, your organization needs to plan to absorb them into the operating budget after the grant period ends.
Your RFP should require vendors to include a post-launch maintenance proposal alongside their build proposal. Even if you're not sure you'll use it, seeing the ongoing cost helps with internal budgeting conversations.
Questions Every Nonprofit Should Require Vendors to Answer
Most website RFP templates focus on what nonprofits should tell vendors. Equally important is what you should require vendors to tell you. These questions protect your organization's long-term interests and are absent from nearly every nonprofit website RFP guide you'll find online.
Are your developers writing custom code, or assembling commercial themes and plugins? This is the question most nonprofits never think to ask, and it has the biggest impact on long-term maintainability. A vendor who builds a custom theme with a limited number of carefully chosen plugins produces a site that will last for years and be straightforward to maintain. A vendor who installs a bloated commercial theme and layers on dozens of plugins produces something that looks the same on launch day but becomes a maintenance headache within a year. Both types of vendors call themselves "developers." Ask which kind you are hiring.
Who owns the code after the project is complete? If the vendor built a custom theme, do you own it outright? Can you take it to another developer? Get this in writing in the contract, not just the proposal.
Who controls the hosting account? Is the website hosted on an account you own and control, or on the vendor's infrastructure? If the vendor disappears or you part ways, can you access your own hosting without their cooperation?
What happens to the site if you stop paying the vendor? Some agencies host clients on proprietary infrastructure where leaving the relationship means rebuilding the site from scratch. You need to know this before you sign, not after.
How does the vendor handle WordPress updates? Core updates, plugin updates, and PHP version upgrades are ongoing requirements for security and compatibility. A vendor who says "we'll build it and hand it off" is leaving you with a ticking clock. Within 18 months of an unattended WordPress site, you'll face security vulnerabilities and potential compatibility breaks.
What does the maintenance retainer actually include? "Monthly maintenance" can mean anything from automated plugin updates (minimal value) to proactive monitoring, security scanning, performance optimization, and priority support (significant value). Get specifics.
Can the site be moved to another host or developer? If the answer involves proprietary systems, custom deployment pipelines, or anything that would require rebuilding, that's a red flag you should take seriously.
These questions aren't adversarial. They're protective. Any vendor who bristles at them is telling you something important about how that relationship will go.
For a complete framework on evaluating what comes back, see our guide on how to evaluate website proposals.
Common Nonprofit RFP Mistakes
Leaving Scope Undefined
Undefined scope is how a reasonable project turns into a fantasy document. Even after the committee reconciles scope with budget, the RFP itself still needs to be explicit. If members need to log in, pay dues, and download invoices, say so. If it is not listed, it is not in scope.
A strong RFP is a checklist of everything the website needs to do. If the list feels incomplete, make scope definition part of the RFP process, with the understanding that budget and timeline may change based on discovery.
Over-Specifying Technology
Nonprofits, often advised by a tech-oriented board member, sometimes specify technical requirements that unnecessarily constrain vendors. "Must use Drupal" when the organization has no Drupal expertise, and WordPress would serve them better and cost less. "Must support 10,000 concurrent users" when the site gets 500 visits per month. "Must include custom API integration with [specific CRM]" when a plugin or embed would accomplish the same goal at a fraction of the cost.
Describe what you need the website to do, not how you want it built. Let the vendor propose the technical approach. That's what you're hiring them for.
Under-Budgeting for Ongoing Costs
This applies to every nonprofit website project, not just grant-funded ones. Organizations that budget nothing for ongoing hosting, maintenance, and security end up with a site that deteriorates within 18 months. WordPress requires regular attention. This is not optional. If you're exploring what nonprofit website hosting and support should include, that's worth understanding before you write your RFP.
Treating It Like Corporate Procurement
Excessive insurance requirements ($2M errors and omissions insurance for a $15,000 website project) price out small vendors who may be the best fit for your project. Net-90 payment terms are unrealistic for small agencies. Requiring in-person presentations to a 12-person committee for a $20,000 project is disproportionate to the investment.
These requirements are modeled on corporate procurement without understanding that they filter out exactly the kind of focused, specialized vendors nonprofits need.
A video call with three to five decision-makers is sufficient for a project at most nonprofit budget levels.
Writing an RFP That Reads Like Every Other RFP
This is my biggest complaint after 25 years: nonprofit RFPs are cookie-cutter. They all say the same things. "Sleek modern design." "Mobile responsive." "SEO optimized." None of that tells me what your organization actually needs.
A modern website should be mobile responsive. That's a given. But rather than stating it as a requirement, ask your responding agency to analyze your actual mobile usage and determine what the mobile experience should be. In our experience, many nonprofit websites have less than 20% of their traffic coming from mobile devices. "Mobile-first design" might be the wrong priority entirely.
Your RFP should describe what you want users to accomplish on the website. Not buzzwords, but outcomes. That's what gives vendors something real to work with and produces proposals you can actually compare. For examples of strong versus weak RFP language, we've put together a side-by-side comparison.
Post-Launch: The Part Nobody Plans For
The biggest risk for a nonprofit website project isn't the build. It's what happens after launch. Because FatLab hosts and maintains sites long-term, we regularly get calls from organizations that just launched a new website but have already decided not to use the vendor who built it for ongoing support.
That dissatisfaction almost always traces back to a loose scope, which traces back to the RFP.
Staff turnover. The person trained to manage the site may leave within the first year. If knowledge isn't documented or transferable, the organization loses the ability to maintain its own site.
Content stagnation. Without dedicated staff time allocated for website content, the site becomes outdated. Board members and donors notice. Six months of stale content communicates organizational neglect, whether that's fair or not.
Technical debt. Skipping WordPress updates, plugin updates, and PHP version upgrades creates compounding security and compatibility risks. Small nonprofits are disproportionately targeted by hackers precisely because they're less likely to keep their software up to date.
What Your RFP Should Require
A training plan. Require detailed training for at least two staff members, with recorded sessions and written documentation. This protects against the single point of failure when one person leaves.
A maintenance proposal. Even if you're not sure you'll use the same vendor for ongoing support, require every responding vendor to include a post-launch maintenance proposal with pricing. This normalizes the conversation about ongoing costs and helps your finance committee plan realistically.
Documentation deliverables. Admin documentation, a content management guide, integration documentation, and a "break glass" document with critical credentials and emergency contacts. If the relationship with the vendor ends, these documents allow your next vendor to pick up where the last one left off.
Technology choices made for sustainability. WordPress powers a majority of the CMS market. That means if your vendor relationship ends, you can find another developer. The same isn't true for proprietary platforms or niche CMS choices. Your technology stack should survive a vendor transition. When you're choosing a web developer, this is one of the most important long-term considerations.
When an RFP Isn't the Right Approach
Not every nonprofit website project needs a formal RFP. If your budget is under $10,000 and your board's procurement threshold allows it, a direct conversation with two or three qualified vendors may produce a better outcome than a formal process.
The RFP format works best when the project is complex enough that you need vendors to propose different approaches to the same problem. For a straightforward brochure site or a theme refresh, the formal process adds months of overhead without proportional benefit.
If you can skip the formal RFP, do your due diligence through conversations, portfolio reviews, and reference checks instead. The questions that reveal real competence are the same regardless of whether they're asked through an RFP or over a phone call. And if your project is specifically a redesign rather than a new build, understanding what a redesign RFP needs to cover will help you scope it correctly, whether you use a formal process or not.
If your board requires a formal process regardless of budget, use it as an opportunity to educate the board on what website projects actually cost and what a realistic timeline looks like. The RFP process itself can be a tool for internal alignment, even when the formal structure isn't strictly necessary for the purchase decision.
The Bottom Line
Nonprofit website RFPs fail when they pretend the nonprofit context doesn't exist. The procurement rules, the committee dynamics, the budget constraints, the grant timelines, and the post-launch sustainability question. These are all real, and they all need to be addressed in your RFP.
The organizations that get the best results are the ones that are transparent about their situation: the budget, the timeline, who's making the decision, and what they can realistically afford.
Quality vendors respond to honesty. We don't respond to theater.
Write a nonprofit website RFP that tells the truth about your organization's needs, constraints, and decision-making process, and you'll get proposals from vendors who actually want to do the work. That's the best possible starting point for a project that needs to succeed.
Frequently Asked Questions
How long should a nonprofit website RFP be?
Most effective nonprofit RFPs run five to ten pages. Anything shorter risks leaving out critical scope details, leading to mismatched proposals. Anything longer usually signals scope creep by committee, where every stakeholder adds requirements without anyone prioritizing them. Focus on what the website needs to accomplish, your budget range, your timeline, and your evaluation criteria.
Should we use a free RFP template we found online?
A template can give you a starting framework, but generic templates overlook everything that makes nonprofit procurement different: board approval requirements, grant-funded timelines, committee dynamics, and the specific integrations nonprofits need, such as donation platforms and CRM systems. Use a template as a skeleton, then customize heavily for your organization's actual situation and constraints.
How long does the nonprofit website RFP process typically take?
From issuing the RFP to signing a contract, plan for six to twelve weeks. That breaks down to two to three weeks for vendors to respond, two to three weeks for evaluation and interviews, and two to four weeks for board approval and contract negotiation. Grant-funded projects often add another two to four months on the front end for procurement compliance before the RFP even goes out.
Who should write the nonprofit website RFP?
The communications director or marketing lead usually owns the drafting process because they best understand the day-to-day website needs. But they should gather input from the development director (donation requirements), program staff (content priorities), and IT or the board tech committee (security and hosting preferences) before writing. One person writes, multiple people contribute. Never write by committee.
Do we need to require vendors to present in person?
For most nonprofit website projects, no. A video call with your evaluation committee of three to five people is sufficient and respects the vendor's time. Requiring in-person presentations for projects under $50,000 filters out remote-capable vendors that may be the best fit for your project and adds weeks to your timeline. Reserve in-person presentations for six-figure projects where the relationship warrants such an investment.
Can we hire a vendor we already know without going through the RFP process?
It depends on your bylaws and procurement policies. Many nonprofits have a threshold, often $10,000 to $25,000, below which sole-source purchasing is permitted. If your project exceeds that threshold, your board likely requires competitive bids. Check your procurement policy first. If you can sole-source, document the rationale; if you cannot, run a genuinely competitive process rather than collecting bids just to check a box.
FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. We offer 20-40% discounts for 501(c)(3) organizations. If you're preparing for a website project and want guidance, get in touch.