Do you need an RFP at all?
You need a formal RFP only if your bylaws, a funder or a procurement policy requires one. If nothing forces you to, a two-page brief sent to three firms gets the same result with less work for everyone. Check your grant agreement first, because some funders require a set number of written quotes for any purchase above a threshold.
Either way, the thinking is the same. You are writing down what the site must do, what you already have, and how you will decide. The ten sections below work for a full RFP or, trimmed down, for a short brief.
The ten sections to include
A useful RFP answers the questions a vendor needs in order to price the work. Anything beyond that is padding.
| Section | What to write |
|---|---|
| 1. About the organization | Mission, who you serve, size of staff, and who will manage the site day to day |
| 2. Why now | What is wrong with the current site, in specifics: "staff cannot edit pages", "donation form fails on phones" |
| 3. Goals | Three to five outcomes, such as more monthly donors, fewer phone calls about program hours, more volunteer sign-ups |
| 4. Audiences | The main groups who use the site and what each needs to do |
| 5. Scope | Approximate page count, content types (events, news, programs, resources), languages, and must-have features |
| 6. Integrations | The giving platform, CRM, email tool and event system you use, by name |
| 7. Content | Who will write and supply content and photos, and how much moves from the old site |
| 8. Requirements | Accessibility level, privacy needs, hosting preferences, who must own accounts and code |
| 9. After launch | Whether you want hosting, maintenance and support quoted, and for how long |
| 10. Process | Timeline, budget or range, how to ask questions, deadline, format of reply, and how you will score |
Section 2 is the one most RFPs skip and vendors value most. A vendor who knows that your real problem is "only one volunteer can update the site" will propose something different from one who is told only that you want "a modern, fresh look". For the design side of those goals, see our guide to web design for nonprofits.
A copy-and-paste outline
Here is an outline you can paste into a document and fill in. Aim for four to six pages. Shorter RFPs get better replies.
- Summary. One paragraph: who you are, what you want, the deadline for replies.
- Background. Mission, programs, current website address, what platform it runs on if you know.
- Problems to solve. A bullet list of what does not work today.
- Goals and how you will measure them.
- Audiences and their top tasks.
- Scope. Pages, content types, features. Mark each feature "must have" or "nice to have".
- Systems to connect. Donations, CRM, email, events.
- Content plan. Who writes, who supplies images, what is migrated.
- Standards. Accessibility, privacy, ownership of domain, accounts and code.
- Hosting, maintenance and support. Ask for this to be priced separately from the build.
- Timeline. Any fixed date, such as a campaign or gala, and why it matters.
- Budget. A figure, a range, or a funding source and its limits.
- What to send back. Approach, team, two or three similar projects, price broken down by phase, and assumptions.
- How you will decide. Criteria, weights, dates, and one contact for questions.
Ask vendors to list their assumptions. That single request surfaces more hidden cost than any other line in the document, and it makes proposals far easier to compare. Our guide on how to compare web development quotes shows what to do with them.
Should you state a budget?
Yes, state a budget or at least a range. Without one, vendors guess, and you receive proposals for three different projects that cannot be compared. With one, every vendor shows you what they can do for the same money, which is the comparison you actually want.
Boards often worry that naming a number means paying that number. In practice, hiding it wastes more money, because your staff spend weeks reviewing proposals you could never afford. If you truly do not know what is realistic, say so, describe your funding source, and ask vendors for a phased option with a smaller first phase.
Also ask for the cost of owning the site after launch. Hosting, updates, security and support continue every year, and a low build price with high running costs is not a saving. Our overview of website maintenance services explains what that ongoing work covers.
How to score the replies
Agree on the scoring sheet before you read a single proposal, so the committee scores against your priorities and not against the best-looking PDF. Four or five criteria are enough.
| Criterion | What a strong reply shows |
|---|---|
| Understanding of your problem | They restate your goals in their own words and respond to section 2, not with boilerplate |
| Approach and scope | A clear list of what is included, what is not, and what they assumed |
| Relevant work | Live sites you can visit on a phone, with a contact you can speak to |
| Team | Named people who will do the work and how you will reach them |
| Total cost of ownership | Build, hosting, maintenance and support shown separately over several years |
Have each committee member score alone first, then compare. Interview the top two. In the interview, ask who owns the domain, hosting and code, and what happens if you leave. The answers tell you a lot. Our checklist for choosing a web development company has more questions worth borrowing.
Mistakes that scare off good vendors
Good firms choose which RFPs to answer. These are the signals that make them pass.
- A very long document. Dozens of pages of procurement language with one paragraph about the actual website.
- No budget and no range.
- Asking for free design work. Requesting mock-ups as part of the proposal means vendors either decline or recycle old work.
- Sending it to twenty firms. Vendors can tell, and the odds make it not worth a careful reply. Three to five is plenty.
- No way to ask questions. Offer a question period or a short call and share the answers with everyone.
- A feature list with no goals. "Must have a slider" tells a vendor nothing about what you need to achieve.
- An unrealistic deadline set by an event rather than by the work.
Next step
If your organization needs a standard informational and fundraising website, you may not need to run this process for the build at all. We design and develop nonprofit websites free of charge. You cover hosting plus a maintenance and support plan, and you get both figures in writing before we start, with no build invoice at the end. The offer has limits: large custom software such as member portals or custom databases, your domain, third-party licenses and payment processing fees are not part of the free build. Read the full terms on our free website for nonprofits page. If your procurement rules still require written quotes, the hosting and support quote we provide is free and can sit alongside the others.
For projects outside that offer, send us your RFP or brief through the contact page, or see how we work with charities on our nonprofit web development page.