How to write a website RFP that gets you bids you can compare.

A website RFP works when every bidder answers the same questions in the same format. Most don't, because the person writing it has never bought a website before. This is the RFP we'd want to receive.

A website RFP works when every bidder answers the same questions in the same format, so you can put the answers side by side and compare price, people and risk. Most website RFPs don't get there. The scope is vague, the budget is hidden and the scoring rewards the lowest build price, which is rarely the lowest cost.

We answer website RFPs from public bodies, associations and firms that sell to government. This is the RFP we'd want to receive, and the one that gets you bids you can actually compare.

What the RFP has to tell bidders.

1. Who the site is for, in order

Name your audiences and rank them. Residents paying a bill, a business applying for a permit and a reporter looking for a meeting agenda need different things from the same site. A ranked list tells bidders where the effort goes.

2. What exists today

Give the numbers: how many pages, how many PDFs and other documents, which forms, which systems the site connects to (payments, permits, agendas, a CRM) and the languages you publish in. "Migrate all existing content" with no count is the biggest single source of bids you can't compare. One bidder prices 200 pages and another prices 2,000.

3. What must be true at launch

List the requirements you can't trade away. For a state or local government in the US that includes the ADA Title II rule, which requires WCAG 2.1 AA (the deadlines and what to fix first). Add where the data must be hosted, your security requirements, records retention and anything your IT team will check.

4. Who will edit the site, and how often

Be honest rather than hopeful. A communications team publishing every day needs a different content system from an office that updates the site twice a month.

5. Your budget range

Publish it. Bidders who have to guess design to their guess, so you get one proposal for $20,000 and another for $200,000 and neither answers your brief. A range lets every bidder show what they would do inside it.

6. The dates

Give the date for questions, the date the answers go to every bidder, the deadline, interviews, the award and the launch you need. Allow at least three weeks to respond. Short windows favor whoever already knew the RFP was coming.

What to ask every bidder.

Ask everyone the same questions, and ask for the answers in the same order.

1. Price in three parts. The build. The first year of hosting and support. Each year after that. A low build price with expensive years two and three is common.
2. The named team. Who does the work, not who presents it, and the role each person plays.
3. Hosting and data. Where the site and its data are hosted, who holds the accounts and how backups work.
4. Accessibility. How they test against WCAG 2.1 AA, with which tools and by whom, plus an accessible site they built that you can test yourself.
5. Content. How many pages and documents the price includes, who rewrites them and how your team is trained.
6. Ownership and exit. Who owns the code, the design and the content. What you get if you leave.
7. References. Two clients like you, with a name and a phone number.

How to score it.

Score the total cost over three years, not the build price. This is the sheet we would use if we were buying.

Keep price at a quarter of the marks or less. A sheet that gives price half the marks picks the bidder who left the most out of their quote.

Mistakes that cost you good bidders.

• Asking for free design work. Mockups made for a proposal are guesses. They tell you who had time to spare, not who will listen.
• Naming a product without a reason. If you need a particular content system because your team already uses it, say why. If not, ask bidders to recommend one and explain the choice.
• A response form nobody can fill in. A locked PDF with small boxes makes every answer worse. Ask for a document in a set order instead.
• Requiring an office within driving distance. Ask for the meetings you need. Most website work happens on video calls, and an office clause shrinks your field for no gain.

Red flags in the answers.

• No price for year two. The cost hasn't gone away. It has been left with you.
• Accessibility promised by a plugin or a widget. Overlay tools don't make a site meet WCAG.
• Results claimed from someone else's project. A percentage from another client's site tells you nothing about yours.
• A team you can't meet before the award.

If you sell to government yourself, your own site gets read the same way. Our checklist for government contractor websites covers what contracting officers look for, and our government contractor websites are built around it.