What to put in a website RFP (and what to leave out)

We read a lot of website RFPs from park districts, municipalities and other public bodies. Most of them make it very hard to compare the bids that come back. The prices land ten times apart, and the evaluation committee has no sound basis for choosing between them. That's almost always down to how the RFP was written.

What to leave out

Leave out the page count. "Approximately 40 pages" invites bids priced by the page, which rewards whoever plans to do the least on each one. Forty pages of text is about two weeks of work. A single program registration that connects to your recreation software can take longer than that on its own.

Leave out the choice of software, unless you have staff who will look after it. Naming a particular content management system narrows the field to whoever already sells it and stops you comparing approaches. Describe what needs to be true instead: staff can edit content without calling a developer, the site is hosted and kept up to date with security fixes, and you can export your content. Then let the vendors make the case for how.

Leave out the design adjectives. "Modern, clean, engaging" appears in nearly every RFP and rules nobody out. If you have real constraints, such as brand colors, an accessible color palette or an existing logo, attach them. Otherwise, ask to see relevant work and judge that.

What to spell out precisely

Start with what a visitor has to be able to do. It drives the price and is usually the vaguest part of the document, so write it as tasks:

• A resident registers a child for a program and pays, without calling.
• A resident finds today's pool hours from a phone in under fifteen seconds.
• Staff post a facility closure in under five minutes, without a support ticket.
• A contractor downloads the current bid packet and its addenda.

A vendor can put a price on each of those, which nobody can do with "modern and engaging."

Next, name the systems the website has to connect to, and their versions. If registration runs through RecTrac, WebTrac, ActiveNet or CivicRec, say which one and which version, and whether your license already includes the access another system needs to connect to it. This is the biggest single factor in the price, and leaving it vague is the main reason bids come back so far apart: half the bidders assume a link out to the registration vendor's own site, and half assume the two systems will be properly connected.

Then name the accessibility standard, WCAG 2.1 Level AA, and say that it covers PDFs, online forms and any third-party tools embedded in the site. As of August 2026, the DOJ's ADA Title II rule sets compliance dates of April 26, 2027 for public entities serving 50,000 or more, and April 26, 2028 for smaller entities and special district governments. Those dates have already been extended once, so check the current rule at ada.gov and have your attorney confirm which category you're in before you build a procurement timeline around it.

Ask each vendor how they test for accessibility, and who does it. Ask what happens to your existing PDF library too, because that's where most districts find the real cost.

Finally, settle who owns what. State that all content, designs and custom code become the district's property, and that you'll get an export in a standard format on request. Ask what happens if you leave in year two.

How to structure the pricing

Ask for the price in three parts, and say you'll evaluate them separately. The first is the build, as a single project figure you can weigh against a capital budget. The second is an annual care plan covering hosting, security updates, backups, accessibility monitoring and support, quoted per year so it can be renewed. The third is an hourly or daily rate for work beyond the approved scope, which most procurement rules require anyway.

Splitting it this way suits how public bodies buy. They bid websites as capital projects, and many can't award an all-in subscription at all. It also stops a vendor hiding ongoing costs behind a low build price, which is the most common way a cheap bid becomes an expensive one.

Ask for third-party costs, such as hosting, software licenses and site search, to be listed separately and passed through at cost. If any are marked up, you want to know before you award, not after.

Two questions worth adding

Ask each bidder to describe a project where they connected a website to your registration system, with a reference you can call. "Do you have experience with" lets them say yes without naming anything.

And ask who specifically will do the work. Agencies tend to bid with their senior people and staff the project with junior ones. Asking for names, and how involved each person will be, makes that harder to slip past you.

A build plus a care plan is how we price websites as standard, because that's the shape procurement needs. If you'd like a second pair of eyes on your scope before it goes out, we're happy to talk it through for free, and it doesn't commit you to inviting us to bid. There's more on our approach on our page for park districts.