A website RFP — a request for proposals — is a document an organization publishes to describe a website project and invite vendors to bid on it. Nonprofits, school districts, municipalities, and state agencies often have to issue one because their procurement rules require competitive bids. Plenty of private businesses write one because it feels like the responsible thing to do.
Here is the uncomfortable part: a badly written RFP does not get you better vendors. It gets you fewer of them, and the ones who answer tend to be the shops with staff whose job is answering RFPs. The firms you actually want are often small, busy, and allergic to spending fifteen unpaid hours guessing at a scope you declined to describe.
So this is both a how-to and a when-not-to.
What an RFP is actually for
An RFP does one useful thing: it makes several different proposals comparable. If four vendors each respond to the same stated goals, the same feature list, and the same budget, you can lay the four side by side and see real differences in approach.
What an RFP cannot do is figure out the project for you. If your board has not agreed on what the new site is for, no amount of vendor response will settle it — you will just get four polite documents that each assume something different, and the decision will come down to which deck looked nicest.
The internal clarity has to come first. The RFP is how you publish it.
Put the budget in the document
This is the single change that most improves the proposals you get back, and it is the one organizations resist hardest. The fear is that naming $40,000 guarantees every bid arrives at $39,500.
In practice, a budget range does not change a vendor’s rates. It changes how much work they can responsibly fit inside them. Withhold it and you force everyone to guess: some overbuild and price themselves out, some underbid and quietly drop the integrations you needed most, and the proposals stop being comparable at all. Agencies say openly that an RFP with no budget is the one they skip.
If you genuinely do not know what the work costs, publish a ceiling instead of a range — “we expect to invest under $35,000” — or ask for proposals at two tiers. Published 2026 estimates for a custom nonprofit or small-business WordPress site with real functionality generally land somewhere between $10,000 and $50,000, with simpler builds below that and multi-portal or multilingual platforms above it. The spread is wide because scope varies enormously, which is exactly why your number helps.
Write requirements, not adjectives
“Modern, clean, and user-friendly” tells a developer nothing. Every proposal will claim all three. Requirements are the sentences a vendor can actually price.
Weak: the site should make it easy to find events.
Strong: staff at each regional chapter need to post their own events without access to the rest of the site, and events must display both on a chapter page and on a statewide calendar.
That second sentence is the kind of detail that decides an architecture. The site Patrick Iverson built for Trout Unlimited New Mexico, the statewide council coordinating local chapters, had to hold exactly that shape of problem — chapters, programs, an events calendar, donation pathways, and action campaigns all living in one structure. None of that is visible in a mood board, and all of it affects the estimate.
Go through your current site and write down what breaks. Those complaints, listed plainly, are better requirements than anything you will invent in a planning meeting.
The sections that earn their space
Most published website RFPs converge on the same handful of sections. Six to eight pages is plenty.
- Who you are — three paragraphs, not your annual report. Who you serve and what you sell or do.
- Why now — the specific trigger. A rebrand, a failing donation form, a site that cannot be edited by staff, a platform nobody will support anymore.
- Goals, in measurable terms — “increase online gifts,” “cut the time to publish a press release from a week to an hour,” “pass an accessibility review.”
- Current state — platform, page count, hosting, who maintains it, monthly traffic, and every third-party system that has to keep working: your CRM, donor database, email tool, point of sale, booking system, MLS feed.
- Scope and requirements — split functional requirements from design ones. Mark each as required or nice-to-have. This section carries the whole document.
- Who does what — content writing, photography, data migration, and training are the four items most often left unassigned, and the four that most often blow up a timeline.
- Budget and timeline — a range, a target launch date, and any immovable deadline behind it.
- How you will decide — your criteria and their weights, your submission deadline, and one named contact for questions.
What to leave out: requests for free spec work. Asking for “initial design concepts” or a sample homepage with the proposal filters directly for whoever has the most idle capacity, which is rarely whoever is best.
Give people time, and invite fewer of them
Two to three weeks is a reasonable response window for a real website proposal. A 48-hour turnaround tells every capable vendor that you have not thought about what you are asking for.
And send it to four or five firms you have already vetted, not fifteen. When a vendor’s odds are one in fifteen with no budget stated, the math stops working and the best ones opt out. A short invited list gets you more effort per proposal and far less to read.
Score the responses against your stated criteria before you open them — strategic approach, relevant work, technical fit, team, references, price — with weights you wrote down in advance. Otherwise price wins by default, because price is the only number that compares cleanly.
Do I have to include a budget in a website RFP?
No rule requires it, and many public-procurement templates omit it. But omitting it reliably makes your results worse. Without a number, vendors guess at scope, the proposals become impossible to compare on anything but cost, and the strongest firms frequently decline to bid at all. If policy prevents you from naming a figure, name a ceiling or request tiered pricing instead — anything that tells a bidder which project you are describing. A range narrows the field to vendors who can actually do the work at that level, which is the point of asking.
When to skip the RFP
If no procurement policy obligates you, consider not writing one. For most small businesses and plenty of small nonprofits, a faster and better path exists:
- Write one page describing the project, the budget range, and the deadline.
- Send it to three vendors whose published work resembles what you need.
- Have a real conversation with each. Thirty minutes on a call reveals more than thirty pages of proposal.
- Pay the finalist for a short paid discovery — scope, sitemap, and a fixed estimate — before committing to the build.
Paid discovery is the honest version of what an RFP is reaching for. It gets you a scoped, costed plan from someone who has actually examined your content, your integrations, and your team — and you own that document whether or not you hire them to build it.
And if you are required to run an RFP, the work above is not wasted. The organizations that get good proposals are the ones that did the thinking before publishing, not the ones with the longest document.
Patrick Iverson is a brand strategist and custom WordPress developer in Santa Fe who has run an independent practice in New Mexico since 2001, and has answered a fair number of these documents. If you are drafting a website RFP and want a second read on the scope section before it goes out, send it over — a half hour now tends to save a round of confused proposals later.
