Should a website RFP include a budget?

Yes, as a range or a ceiling. Without one, bidders guess at your level of ambition and their proposals cannot be compared. A budget signal lets each bidder propose the best solution they can deliver for that amount, which is the thing you actually want to evaluate.

How long should a website RFP be?

Long enough to describe your situation clearly, which for most organizations is a handful of pages plus attachments such as a content inventory summary. Length is not the goal. A short, specific RFP produces better proposals than a long one padded with generic requirements copied from elsewhere.

Should we ask agencies for design concepts in the proposal?

Generally no. Speculative design is produced without discovery, so it shows you who is good at pitching rather than who understands your problem. Ask for case studies, a description of the design process and examples of how earlier work was measured after launch.

How many vendors should receive a website RFP?

Enough to get a real comparison without burying your evaluation committee. Many private organizations invite a short list of qualified firms directly. Public bodies usually have procurement rules that set how the opportunity is posted, so confirm those with your procurement office before drafting.

How to Write a Website RFP That Produces Better Proposals

Why most website RFPs get weak proposals

When a website RFP produces disappointing bids, the instinct is to blame the vendors. Usually the document is the problem. Bidders can only price what they can see, and most RFPs give them very little to see.

The common failures are predictable. The scope is described as a list of pages, so bidders price page counts. Integrations are mentioned in passing (“must connect to our CRM”) without naming the system or what should flow into it, so bidders either pad the number or leave it out and plan to raise a change order. There is no budget signal, so a small studio and a large agency submit numbers that differ by a multiple and nobody knows which one understood the job. And the evaluation is weighted towards design samples, which tells you who has a good portfolio, not who will run your project well.

The fix is not a longer RFP. It is a more specific one. This guide is for any established organization buying a website build. If you are a municipality, read the RFP mistake every municipality makes on a website rebuild as well, because public bodies carry obligations a private company does not. If you are hiring an agency for ongoing marketing rather than a website project, what to include in a marketing agency RFP is the better starting point.

The sections every website RFP needs

A good website RFP is mostly a description of your situation. Here is the structure we would want to receive as a bidder, in order:

About the organization. What you do, who you serve, where, and how the website fits into how you win business. A paragraph or two, not the annual report.
Objectives and measures. Three to five outcomes the new site must deliver, each with how you will know. “More qualified inquiries, measured as form submissions sales accepts” is an objective. “A modern look” is not.
Audiences and tasks. Who visits, ranked by importance, and what each group needs to do.
Current state. The current platform, approximate page count, which sections get the most traffic, what is working and what is not. Attach a summary of your content inventory if you have one.
Functional requirements. Forms, search, filtering, booking, member areas, events, job postings. Describe what each must do, not how to build it.
Integrations. Named systems and the data that moves between them (more on this below).
Content. Who is writing, who is translating, whether photography or video is needed, and how much existing content migrates.
Accessibility and languages. The standard, the conformance level and how it will be verified. Which languages, and whether parity is required.
Editing and ownership. Who will maintain the site and their skill level. A requirement that you own the domain, code, content and analytics outright.
Budget and timeline. A range or ceiling and a target launch window, with any dates that cannot move.
Submission requirements and evaluation. What to submit, the deadline, the question period, the evaluation criteria and their weights.

If sections two through four feel hard to write, that is a signal. You may need a discovery phase before you go to market. A short paid discovery, or an internal one, produces exactly the inputs an RFP needs, and the guide to website discovery before design covers what it should settle.

Requirements that bidders can actually price

The test for every requirement is whether two competent vendors would read it the same way. “User-friendly navigation” fails. “A visitor on a phone can find our nearest location’s hours in two taps from any page” passes.

Integrations

Integrations are the biggest source of surprise cost in website projects, because they are easy to mention and hard to scope. For each one, state:

The system by name (your CRM, email platform, booking or payment tool).
What data moves, in which direction, and when.
Whether an existing integration needs to be preserved or replaced.
Who on your side administers that system and can answer questions.

“Contact form submissions create a lead in our CRM with the service of interest and the page they came from” can be priced. “CRM integration” cannot. The integration requirements guide has a fuller checklist, including consent and analytics.

Accessibility

Name the standard. The Web Content Accessibility Guidelines (WCAG) are the usual reference, and you should specify the version and conformance level you require. Then say how it will be verified: an audit before launch by someone other than the builder, plus training for your editors so the site stays compliant as content is added. “The site will be accessible” with no standard and no test is a box every bidder will tick. Practical planning for this is covered in website accessibility planning for Canadian organizations.

Content migration

State how many pages exist, roughly how many you expect to keep, and whether the vendor or your team moves them. Content migration is labour, and an RFP that is silent on it will get bids that assume someone else does it.

State a budget, even a rough one

Many organizations hold back the budget on the theory that bidders will spend whatever they are told. In practice the opposite happens. Without a budget signal, a proposal is a guess about how much ambition you want. One bidder proposes a template site, another proposes a custom build with a content strategy and an accessibility audit, and you cannot compare them because they are not answering the same question.

A range or ceiling lets every bidder propose the best solution they can deliver within it, which is what you actually want to evaluate. If you are unsure what a realistic range is for your scope, the drivers are laid out in what a business website costs in Canada. A credible number depends on scope, which is why scoping first and budgeting second usually produces a better range than picking a figure in a budget meeting.

Also ask bidders to price year two and year three separately: hosting, licences, security updates, support and training. The build is a one-time cost. The ownership cost is what you live with.

What not to ask for

Some common RFP requirements produce worse proposals, not better ones:

Speculative design. Asking bidders for homepage mockups rewards the ones willing to work for free on a surface they know nothing about. You learn who is good at pitching. Ask for case studies and a description of their design process instead.
A named platform without a reason. If you need a specific CMS because your team already uses it or an integration depends on it, say so and say why. Otherwise describe the editing needs and let bidders recommend.
Unrealistic timelines. A launch date that ignores content writing, translation and approvals gets you bidders who either promise it and miss, or quietly descope.
Boilerplate pages of requirements copied from another RFP. Bidders can tell. Copied requirements that do not apply to you add cost and noise.

How to evaluate proposals fairly

Publish your criteria and weights in the RFP. Public bodies are generally expected to do this under their procurement rules, and it is good practice everywhere because it tells bidders what to emphasize. A reasonable starting set:

Understanding of the problem. Did they restate your objectives in their own words and say how they would measure them?
Approach and process. Discovery, content, design, development, testing and launch, with your responsibilities spelled out.
Relevant experience. Comparable projects, with results they can show, and references you can call.
Team. Who actually does the work, and how senior they are.
Ownership and post-launch. Training, documentation, support, exit terms.
Cost. Build plus the multi-year ownership cost, compared like for like.

Score independently before discussing as a group, so the loudest voice in the room does not set everyone’s numbers. Interview a short list. In the interview, ask each finalist to walk through a project that went wrong and what they changed afterwards. The answer tells you how they will behave on yours.

A question period matters more than people think. Publish all questions and answers to all bidders. The questions themselves are informative: a bidder who asks about your CRM fields and your translation workflow has read the document properly.

An illustrative example

Consider a hypothetical professional association in Atlantic Canada with a dated site, a member directory and an events calendar. Its first draft RFP asks for “a modern, mobile-friendly website with member login and events,” with no budget and a launch in ten weeks. The bids range wildly and none of them mention the association’s membership database.

The revised RFP names the membership system and states that member status must sync nightly. It lists the event types and says registrations must flow into the same system. It requires English and French parity for public pages, names a WCAG conformance level with an independent audit, gives a budget ceiling, and moves the launch to avoid the annual conference. The second round of proposals is comparable, two bidders ask sharp questions about the membership data, and the evaluation committee can actually explain its choice to the board.

Nothing about the second RFP is complicated. It is just specific. That is the whole trick, and it is how we would want to receive one when bidding on website design and development work ourselves.