What a nonprofit website RFP is, when it's worth writing one, and a full section-by-section sample you can adapt directly — from project overview through evaluation criteria.
A Request for Proposals (RFP) is a written document nonprofits send to web agencies asking them to propose how they'd approach a project — including scope, timeline, cost, and team. It gives every vendor the same information, so their proposals can be compared fairly instead of judged on whoever asked the best follow-up questions.
Done well, an RFP does most of the discovery work before a single call happens: it forces your organization to agree internally on goals, budget, and scope before you ask vendors to guess at them.
Pick your project type, scope modules, budget, and timeline — get a formatted document ready to send, in Word or PDF.
Copy the section headers as-is, or adapt them to your project. The italic sample text under each is a realistic starting point — replace the bracketed placeholders with your organization's specifics.
One paragraph: what you're building, why now, and the outcome that defines success. Vendors triage RFPs fast — a vague overview gets a generic proposal back.
Sample language
[Organization name] is requesting proposals for a redesign of our public website (currently on [CMS/platform]). The current site was launched in [year] and no longer supports our [donation / program enrollment / advocacy] goals. We are seeking a partner to lead strategy, design, development, and launch, with a target go-live of [date].
Mission, programs, size, and audience — enough that a vendor unfamiliar with your sector can write a proposal that isn't generic agency boilerplate.
Sample language
[Organization name] is a [501(c)(3) / government agency / association] founded in [year], serving [population/geography]. Annual budget is approximately [$ range]. Core programs include [list]. Primary audiences for the website are [donors / clients / members / policymakers / general public].
Specific, prioritized goals — not "look more modern." Rank them if you can; it tells vendors what to optimize for when tradeoffs come up.
Sample language
1. Increase online donation conversion rate. 2. Make it possible for program staff to publish and update content without a developer. 3. Improve mobile experience and page speed. 4. Preserve current organic search rankings through the migration. 5. Meet WCAG 2.1 AA accessibility standards.
List what's in scope by category — discovery, design, content, development, integrations, QA, launch, training — and explicitly flag anything you know is out of scope.
Sample language
In scope: discovery & IA, UX/UI design, CMS template development, content migration for up to [N] pages, CRM and donation platform integration, GA4 setup, accessibility-oriented build, staff training. Out of scope: logo/rebrand, native mobile app, translation into languages beyond [list].
State plainly who is writing, editing, and migrating content — this single line prevents more scope disputes than any other section.
Sample language
[Organization] will provide final copy for all pages by [date]. Vendor is responsible for content migration, formatting, and image optimization. [Vendor / Organization] is responsible for new copywriting, if included in the proposal.
Name a standard, not just "accessible." If you have a compliance deadline (ADA Title II, state policy, funder requirement), say so — it changes how vendors scope QA and testing.
Sample language
The site must meet WCAG 2.1 Level AA at launch, including keyboard navigation, screen-reader-compatible forms, and color contrast. Proposals should describe accessibility testing methodology (automated and manual) and note any post-launch retesting included.
List every system the site needs to talk to — CRM, donation processor, email platform, event or membership tools — with the current vendor named for each.
Sample language
CRM: [Salesforce NPSP / Bloomerang / EveryAction / other] Donation processor: [Donorbox / Classy / Stripe / other] Email platform: [Mailchimp / Constant Contact / other] Analytics: Google Analytics 4 Other: [event registration, membership portal, advocacy/action tools, etc.]
If this is a redesign or replatform, this is the section that prevents a traffic cliff. Ask directly how each vendor protects rankings during migration.
Sample language
Vendor must provide a 301 redirect plan for all existing indexed URLs, preserve or improve current keyword rankings, maintain existing metadata and schema where applicable, and submit updated sitemaps to Search Console at launch. Describe your SEO-safe migration process in your proposal.
Name your preferred platform if you have one, or ask vendors to recommend one and explain why. Note hosting, staff technical comfort level, and any existing licenses.
Sample language
Preferred CMS: [WordPress / open to recommendation]. The site must be editable by non-technical staff without developer support for routine content updates. Note your recommended hosting approach and any ongoing platform costs in your proposal.
A range, not silence. "Contact us for pricing" from every vendor wastes weeks. A stated range filters out mismatched proposals before anyone's time is spent.
Sample language
Estimated budget range for this project: $[X] – $[Y]. Please provide a fixed project fee or a not-to-exceed estimate broken out by phase (discovery, design, development, content, QA/launch), plus any ongoing hosting or maintenance costs.
State any hard deadline (a fundraising event, fiscal year, grant deliverable) and your target launch window — then ask vendors to propose a realistic phase-by-phase schedule.
Sample language
Target launch date: [date]. Hard deadline (if any): [event/date and why it's fixed]. Please provide a proposed project timeline broken into discovery, design, development, content/QA, and launch phases, with estimated duration for each.
Tell vendors exactly what to submit so proposals arrive in a comparable format — this is what makes evaluation fast instead of miserable.
Sample language
Proposals should include: agency overview and relevant nonprofit experience, 3+ relevant work samples, proposed approach and methodology, team bios for assigned staff, itemized cost breakdown, proposed timeline, three references (ideally nonprofit clients), and standard contract/MSA terms.
Publish how you'll score proposals — even a simple weighted list. It disciplines your own review process and signals a serious, fair procurement to vendors.
Sample language
Proposals will be evaluated on: relevant nonprofit experience (25%), proposed approach and understanding of our goals (25%), team qualifications (15%), cost and value (20%), timeline feasibility (10%), references (5%).
Deadline, format, contact person, and question process — the logistics that keep the process fair and organized.
Sample language
Proposals are due by [date, time, timezone] via email to [name, email]. Questions must be submitted in writing by [date]; answers will be shared with all invited vendors. Anticipated timeline: proposals due [date], finalist interviews [date range], award notification [date].
Common mistakes
Every serious agency will ask; withholding it just adds a round-trip email and filters nothing.
"Modernize our online presence" tells a vendor nothing about what to prioritize when scope and budget collide.
A 6-week RFP window for a 12-week build with a 2-week decision deadline gets you either a rushed proposal or none at all.
Without stated criteria, review often defaults to whoever presents best rather than whoever fits the project.
Nonprofit context — donor trust, accessibility, board oversight, grant compliance — gets lost, and proposals come back generic.
Name one person who owns the final decision. A seven-person committee with equal votes rarely finishes on schedule.
A strong RFP gets you comparable proposals. These are the questions worth asking beyond the document itself before you sign.
A beautiful e-commerce portfolio doesn't tell you whether an agency understands donor UX, board reporting needs, or grant-funded content constraints.
"We can add that" is a different answer than a described testing methodology. Accessibility bolted on late is expensive and incomplete.
Who fixes a broken form six weeks post-launch? Maintenance, training, and documentation should be explicit in every proposal.
The cheapest proposal with the vaguest process is usually the most expensive project by month four.
A reference from a client still mid-project is different from one who worked with the agency through launch and beyond.
For a deeper look at evaluating agencies specifically, see how to choose a nonprofit website agency.