A website RFP template nonprofits can actually use

Most nonprofit website RFPs get bad proposals because they ask several vendors to price a project nobody has defined yet. The fix is not a longer document. It is a clearer one that states four things — what you are trying to accomplish, what has to exist when you launch, when you need it, and how much you have to spend. The full template is below, section by section, written so you can copy it into a document and fill it in this afternoon.

I have read a lot of these over 14 years, and the difference between an RFP that gets three good proposals and one that gets nine useless ones almost never comes down to writing quality. It comes down to whether the document contains enough information for a vendor to commit to a number without guessing.

Do you actually need an RFP?

Probably not, unless someone is making you. An RFP is a procurement tool designed for situations where you must be able to show that you ran a fair, documented competition. If your bylaws require it, if a foundation grant requires it, if you hold a government contract with procurement rules attached, run one.

If none of that applies, a shorter path usually works better. Write a one-page scope, send it to three studios whose work you have actually looked at, and ask each for a fixed-fee proposal. You will get the same information in half the calendar time.

And if your total budget is under $3,500, do not run an RFP and do not hire an agency, including us. At that number the procurement process eats a meaningful share of the money. A Squarespace or WordPress template plus ten to twenty hours of paid help from a freelance designer will get you a real website. Our own pricing page starts a Starter site at $1,800 to $3,500 precisely because that tier is a scoped, limited engagement — it does not include the discovery, stakeholder interviews, and content strategy that an RFP process implies you want. Do not pay agency overhead for template work.

The RFP earns its keep somewhere around $10,000 and up, or any time three or more people have to agree on the decision.

What goes in a nonprofit website RFP?

Thirteen sections. Four to eight pages total. Here is the whole structure and why each piece changes the proposals you get back.

Section	Length	Why it changes the proposals
1. Organization background	1-2 paragraphs	Lets a vendor tell you whether they have done this kind of work
2. Project goals and measurable outcomes	Half a page	The single biggest driver of proposal quality
3. Current site and what is wrong with it	Half a page	Stops vendors from proposing fixes you already tried
4. Audiences	Short list	Determines information architecture and tone
5. Required functionality	Checklist	Where most cost variance actually lives
6. Content responsibility	1 paragraph	The most common cause of blown timelines
7. Accessibility requirement	1 paragraph	Cheap to specify up front, expensive to retrofit
8. Technical requirements and ownership	Short list	Protects you from being locked into a vendor
9. Timeline and key dates	Table	Filters out vendors who cannot actually staff it
10. Budget range	2 sentences	Makes proposals comparable to each other
11. Evaluation criteria with weights	Table	Keeps your own committee honest
12. Submission instructions	Short list	Saves you a week of chasing formats
13. Questions vendors must answer	8-12 questions	Turns marketing decks into real answers

The template, section by section

Copy each block. Replace anything in square brackets. Delete what does not apply to you.

1. Organization background

## 1. About [Organization Name]

[Organization Name] is a [501(c)(3) nonprofit / public charter school /
faith-based organization] based in [City, MN], founded in [year]. We
[one sentence on what you do and who you serve].

Scale: [X] staff, [X] volunteers, [X] people served annually,
annual operating budget of approximately $[X].

Primary funding sources: [grants / individual giving / government
contracts / tuition / program fees].

Vendors use this to judge fit, not to flatter you. A studio that has built for nonprofits knows the difference between a grant-funded organization with one communications staffer and a membership organization with a marketing team. Say which one you are.

2. Project goals and measurable outcomes

## 2. Goals

In priority order, this project must:

1. [Goal] — measured by [metric], currently [baseline], target [number]
   within [timeframe] of launch.
2. [Goal] — measured by [metric], currently [baseline], target [number].
3. [Goal] — measured by [metric], currently [baseline], target [number].

Out of scope for this project: [things you are explicitly not doing].

This is the section that separates a serious RFP from a wish list. “Modernize our web presence” tells a vendor nothing. “Increase online donations from 40 per month to 100 per month within six months” tells them to spend budget on the giving flow instead of the photo gallery.

If you do not have baseline numbers, go get them before you release the RFP. Open Google Analytics and your donation platform and write down monthly sessions, monthly online gifts, average gift size, and form submissions. Twenty minutes of work here improves every proposal you receive.

The “out of scope” line is underrated. Writing “we are not migrating our donor database in this project” prevents three vendors from padding their number against a risk that does not exist.

3. Current site and what is wrong with it

## 3. Current site

URL: [url]
Platform: [WordPress 6.x / Squarespace 7.1 / Wix / custom / unknown]
Built: [year] by [vendor, or in-house, or unknown]
Approximate page count: [X]
Who can edit it today: [names/roles]
Hosting: [provider], $[X]/mo, [who holds the account]
Domain registrar: [provider], [who holds the account]

Known problems:
- [Specific problem, e.g. "the donate button is below the fold on mobile"]
- [Specific problem]
- [Specific problem]

What we want to keep: [what actually works]

Be blunt here. Vendors are not judging you for a dated site; they are trying to figure out how much of the existing thing survives. The “what we want to keep” line saves good content from being thrown out for no reason.

The hosting and registrar lines matter more than people expect. If nobody at your organization knows who holds the domain, find out before the RFP goes out — our guide on how to check whether you own your website walks through it. A migration where the previous developer is unreachable is a different project than one where you control the accounts, and vendors need to price that difference.

4. Audiences

## 4. Audiences

Primary: [audience], who come to the site to [task].
Secondary: [audience], who come to the site to [task].
Tertiary: [audience], who come to the site to [task].

Language needs: [English only / English + Somali / English + Spanish /
other]. [Note whether translation is professional, machine, or not needed.]

Device split from analytics: [X]% mobile, [X]% desktop.

Rank them. Every website has to serve several groups and most sites fail because the homepage tries to speak to all of them equally. If your primary audience is a family looking for services and your secondary audience is a funder doing due diligence, those are different pages, not competing halves of one page.

Language matters for a lot of Minnesota organizations, and it is a real budget line. If your programs serve East African families in Minneapolis or Saint Paul, say whether you need Somali or Oromo content and whether you will supply the translations. Machine translation of a program eligibility page is not acceptable, and a vendor needs to know that up front.

5. Required functionality checklist

## 5. Functionality

Must have at launch:
- [ ] Online donations via [platform, e.g. Givebutter, Classy, Stripe]
- [ ] Recurring gift option
- [ ] Events calendar with [registration / no registration]
- [ ] News or blog with [X] categories
- [ ] Staff and board directory
- [ ] Program pages, approximately [X]
- [ ] Contact form routing to [address]
- [ ] Volunteer application form
- [ ] Email signup connected to [Mailchimp / Constant Contact / other]
- [ ] Document library for [annual reports / 990s / policies]
- [ ] Search
- [ ] Mobile-first responsive layout

Nice to have, priced separately as options:
- [ ] Password-protected board or member area
- [ ] Multilingual content
- [ ] Job board
- [ ] Interactive impact map or dashboard
- [ ] Client/participant portal

Integrations required: [CRM name], [donation platform], [email tool],
[any state reporting system].

Separate must-have from nice-to-have and ask for the nice-to-haves to be priced as line-item options. Now you can trim to budget after you pick a vendor instead of before you know what things cost.

Integrations are where quotes diverge the most. Connecting a form to Mailchimp is an hour. Two-way syncing with a CRM like Salesforce NPSP or Neon is a project of its own. Name the actual system, not the category.

6. Content responsibility

## 6. Content

We will supply: [existing copy / photography / logo files / brand guide].
We need the vendor to supply: [copywriting for X pages / photography /
photo sourcing / editing of existing copy].

Content owner on our side: [name, title, hours available per week].
Target date for all content delivered to vendor: [date].

Late content is the single most common reason a nonprofit website launches three months behind schedule. Not development. Content.

Name one person, and be honest about their availability. If your executive director is the only one who can approve program copy and she has four hours a month, say so, and either budget for a copywriter or extend the timeline. A vendor who knows this can plan around it. A vendor who finds out in week six cannot.

7. Accessibility requirement

## 7. Accessibility

The delivered site must conform to WCAG 2.1 Level AA. The vendor will
describe in their proposal how they test for conformance, including which
manual checks they perform beyond automated scanning.

Automated scanning alone is not sufficient. Overlay or widget-based
accessibility products are not acceptable as a conformance strategy.

Write this in even if no regulation names you. WCAG 2.1 Level AA is the level cited in federal rules, in grant agreements, and in accessibility complaints and settlements generally, and it costs very little to build in from the start compared to retrofitting later. Our accessibility guide for small organizations covers what conformance actually involves.

The line about overlays is deliberate. Widget products that promise one-line compliance do not deliver it, and the accessibility community has publicly opposed them for years. Ruling them out in the RFP prevents a vendor from quoting a cheap number that relies on one.

8. Technical requirements and ownership

## 8. Technical and ownership requirements

- Platform: [we prefer X / vendor to recommend with rationale]
- The site must be editable by non-technical staff without HTML.
- All code, design files, and content are owned by [Organization] on
  final payment. Vendor retains no license restrictions on our use.
- All accounts (hosting, domain, CMS, analytics) will be registered to
  [Organization] email addresses with [Organization] as owner.
- Site must load a typical page in under 3 seconds on a mobile
  connection. Vendor should state target Core Web Vitals.
- Vendor will provide written documentation and a recorded training
  session for our staff.
- Hosting recommendation with monthly cost stated separately.
- 30 days of post-launch bug fixes at no additional cost.

The ownership clause is the most important paragraph in the entire RFP and it takes four lines. Plenty of small organizations discover during a redesign that their domain is registered to a former board member’s personal account.

Stating who owns the accounts before the project starts prevents that permanently. Any vendor who pushes back on it is telling you something useful.

9. Timeline and key dates

## 9. Timeline

| Milestone | Date |
|---|---|
| RFP released | [date] |
| Written questions due | [date] |
| Answers posted to all bidders | [date] |
| Proposals due | [date, 5:00 PM Central] |
| Finalist interviews | [date range] |
| Vendor selected | [date] |
| Project kickoff | [date] |
| Content delivered to vendor | [date] |
| Target launch | [date] |

Hard constraint: [e.g. "must launch before our Give to the Max Day
campaign on [date]" or "before enrollment opens [date]"]. If your
proposed schedule cannot meet this, say so directly rather than
proposing a date you cannot hold.

Give vendors two to three weeks to respond. Under ten business days and you get recycled material, because nobody can do original thinking about your organization in a week while running current projects.

Name the hard constraint explicitly. A Minnesota nonprofit that needs to launch before Give to the Max Day in November has a real deadline, and so does a charter school that needs enrollment pages live before the lottery opens. A typical business website takes four to eight weeks of build time after content is ready, so count backward from the constraint and check that your own dates are physically possible before you publish them.

10. Budget range

## 10. Budget

Our approved budget for this project is $[X] to $[Y], inclusive of
design, development, testing, training, and launch. Ongoing hosting and
maintenance should be quoted separately as monthly costs.

We are more interested in how you allocate this budget than in the
lowest number. Proposals that exceed the range will be considered only
if the additional scope is clearly justified.

Why does hiding your budget produce worse proposals?

Because a website is not a commodity with a fixed specification. The same list of pages can be built for $4,000 or $40,000, and both are legitimate projects — they just make completely different tradeoffs about custom design, content strategy, integrations, and testing.

When you withhold the number, three things happen and none of them help you:

You get non-comparable proposals. Vendor A assumes $6,000 and proposes a template build. Vendor B assumes $35,000 and proposes discovery workshops and a custom design system. You are now comparing two different projects, not two approaches to the same one.

Good vendors bid high or decline. A studio that cannot see the budget has to price for the worst case, because a lowball estimate against an ambiguous scope is how firms lose money. The careful ones inflate. The busy ones skip your RFP entirely.

You lose the actual signal. The useful question is not “who is cheapest” — it is “given the same $15,000, who gets the most out of it?” That comparison is only possible if everyone is working from the same number.

The fear behind budget secrecy is that vendors will simply quote your maximum. Some will. That is exactly why you also state the evaluation weights: if price is 15 percent of the score and approach is 25 percent, quoting the ceiling with a thin plan loses. And a vendor who quotes $18,000 for what another quotes at $11,000 has to defend the difference in writing, which is far more informative than a blind number.

If you genuinely cannot publish a number because of board politics, publish a not-to-exceed ceiling instead. “Proposals must not exceed $20,000” is less useful than a range but far better than silence. Our nonprofit website budget guide has realistic ranges by organization size if you need help setting one.

11. Evaluation criteria with weights

## 11. How proposals will be evaluated

| Criterion | Weight |
|---|---|
| Relevant experience with similar organizations | 30% |
| Proposed approach and understanding of our goals | 25% |
| Team, communication plan, and references | 20% |
| Cost and value within our stated range | 15% |
| Accessibility practice and post-launch support | 10% |

Proposals will be scored by a [X]-person committee. Finalists may be
invited to a 45-minute interview. We reserve the right to request
clarification, to negotiate scope, or to select no vendor.

12. Submission instructions

## 12. How to submit

Send one PDF, no more than [12] pages plus appendices, to [email] by
[date] at 5:00 PM Central. Include:

- Firm name, primary contact, phone, email
- Answers to the questions in Section 13
- Three examples of comparable live sites you built, with URLs and a
  one-paragraph description of your role in each
- Three client references, at least one from a nonprofit
- Line-item budget and payment schedule
- Proposed project schedule with milestones
- Named team members who will do the work

Written questions may be submitted to [email] until [date]. All
questions and answers will be shared with every bidder on [date].

The shared question-and-answer step is worth the small amount of work it takes. It keeps the process fair, and the questions vendors ask will expose gaps in your own RFP while you still have time to fix them.

13. Questions vendors must answer

## 13. Questions

1. Which of your past projects is most similar to ours, and why?
2. Who specifically will work on this project, and what percentage of
   their time will it take?
3. What platform do you recommend for us, and what are the tradeoffs
   of that choice?
4. How do you handle content — do you write, edit, or only place it?
5. How do you test for WCAG 2.1 AA conformance?
6. What happens if our content is late? How does that affect the schedule?
7. What is not included in your price that we should budget for?
8. Who owns the code, design files, and accounts after launch?
9. What does support cost after launch, and what does it include?
10. Describe a project that went badly and what you changed afterward.
11. What do you need from us, and how many hours per week?
12. If our budget were cut by 30 percent, what would you cut first?

Questions 7, 10, and 12 do the heavy lifting. Anyone can answer the first six from a template. The last three require a vendor to think about your situation specifically, and the answers tell you more about how the project will actually feel than a portfolio does.

How do you score proposals fairly?

Use the grid you published, score independently, then meet. Have each committee member score every proposal on their own before any discussion, or the loudest person in the room sets the anchor.

Score everything except price first, with pricing pages removed if you can manage it. Then add price. A cheap proposal with a weak plan should not win on the strength of one number, and reviewing blind for the first pass is the simplest way to prevent that.

Criterion	Weight	Vendor A	Vendor B	Vendor C
Relevant experience (0-10)	30%	9 = 2.7	6 = 1.8	7 = 2.1
Approach and understanding (0-10)	25%	8 = 2.0	9 = 2.25	5 = 1.25
Team and communication (0-10)	20%	7 = 1.4	8 = 1.6	6 = 1.2
Cost and value (0-10)	15%	6 = 0.9	5 = 0.75	9 = 1.35
Accessibility and support (0-10)	10%	9 = 0.9	7 = 0.7	4 = 0.4
Total	100%	7.9	7.1	6.3

Vendor C is the cheapest and finishes last. That is the grid doing its job.

Two rules keep this honest. Write a one-sentence justification for every score under 5 or above 8, which forces reviewers to point at something in the document. And call every reference — ask each one what surprised them, what they would do differently, and whether the vendor is still responsive today.

What does a good proposal look like versus boilerplate?

You can usually tell in the first two pages. The tells are consistent.

Boilerplate proposal	Real proposal
Restates your RFP back to you	States what it thinks your actual problem is, which may differ from what you wrote
Portfolio of unrelated work	Two or three genuinely comparable projects with live URLs
“Our proven 5-phase process” with no dates	A schedule with named milestones tied to your deadline
One lump-sum price	Line items, with options priced separately
No questions asked during the window	Asked two or three specific questions that made you think
Agrees with everything	Pushes back on at least one thing in your RFP
Team described as “our experts”	Named people with roles and time commitments
Accessibility mentioned once as “ADA compliant”	Names WCAG 2.1 AA and describes the manual testing
Support described as “we’re here for you”	A monthly number and a list of what it covers

The pushback item matters most. If you asked for something that will not serve your goals — a homepage video carousel, a custom donation form when your processor’s hosted form converts better — a vendor worth hiring will say so in the proposal. Total agreement in a written bid usually means the vendor plans to build whatever you ask and hand you the bill.

What we do differently when a nonprofit RFP arrives

We will tell you when the project you described is bigger than it needs to be. That has cost us work, and it is still the right call. If a $22,000 rebuild request is really a $4,000 navigation-and-donation-flow fix on a site that is otherwise fine, saying so is more useful to a program-funded organization than winning the bid.

You can see the range of what this looks like in practice across our nonprofit work, including sites like Bridge and Bloom and HARO. Before you send anything out, it is also worth reading the 15 questions to ask before you hire a web designer — several of them belong in Section 13 of your own RFP.

If you want a second read on a draft RFP before it goes out, send it over through our contact page. No charge and no obligation to include us in the bid list. A clearer RFP produces better proposals from everyone who responds, which is a fine outcome either way.