A website RFP is a filter. Write it well and you get five comparable proposals from firms that understood the work. Write it poorly and you get fifteen proposals that cannot be compared to each other, from firms that guessed, priced the guess defensively, and will issue change orders the moment reality arrives.
The quality of the bids you receive is largely determined before you send anything. Here is what separates an RFP that attracts good work from one that repels it.
Decide what the document is for
An RFP is not a specification. If you could specify the site precisely, you would not need a partner, you would need a contractor and a fixed price. An RFP is a description of a problem, a set of constraints, and an invitation for firms to show you how they would approach it.
This distinction matters because the most common failure is an RFP that over-specifies solutions and under-specifies outcomes. Requiring a particular plugin, a particular page count or a particular navigation structure removes exactly the expertise you are paying for, and it guarantees that every proposal looks the same except for price.
Lead with the problem, not the feature list
Open with why you are doing this. Not “our site is outdated,” which tells a bidder nothing, but the specific operational facts: staff cannot publish without a developer, the forms do not work on mobile, the French section stopped being maintained two years ago, search sends people to the wrong department, the site failed an accessibility review.
Those statements let a bidder tell you which of your problems is the expensive one. That is the most useful thing a proposal can do, and a feature list never produces it.
Include the facts bidders cannot guess
Most price variance between proposals comes from bidders making different assumptions about the same unknowns. Remove the unknowns and the proposals become comparable.
- Scale. Number of pages and number of documents, from an actual crawl rather than an estimate. These two numbers move a quote more than anything else in the document.
- The current platform, its version, and whether content can be exported.
- Integrations, named. Which systems, which vendors, and whether documented APIs exist.
- Languages, and the level of parity you are committing to maintain.
- The accessibility standard, with a version number. “Accessible” is not a requirement. “WCAG 2.2 Level AA” is.
- Who writes the content. State plainly whether copy is being reused, rewritten by you, or expected from the bidder.
- Hosting, and whether the winning firm inherits it or replaces it.
- Who decides. Name the decision-maker and the approval path. Bidders price committee approval differently from delegated authority, and they are right to.
Publish the budget range
This is the recommendation organizations resist most, and it is the one that improves bid quality most.
Withholding the budget does not produce competitive pricing. It produces proposals scoped at different sizes, which cannot be compared, and it wastes the time of firms whose floor is above your ceiling. Publishing a range lets every bidder scope to the same envelope, so your comparison is about approach and capability rather than about who guessed your number.
If a range is genuinely impossible, say what the project is worth in outcome terms, or ask for pricing against defined options. Anything is better than silence.
Ask for fewer things, and better ones
Long submission requirements select for firms with proposal departments, not firms with good developers. Four requests will tell you more than fourteen:
- How would you approach this, and what would you do first? The order someone proposes reveals how they think.
- Two comparable projects, with what went wrong. Any firm can supply references. A firm that can describe a problem and how it was handled is telling you what you will actually experience.
- Who will do the work, by name, with their availability. The gap between the team who pitches and the team who builds is the most common source of disappointment in this industry.
- What happens after launch, and what it costs. A firm with no answer here is a firm planning to disappear.
Do not ask for free design work. Speculative mockups are produced without research, tell you nothing reliable, and the best firms decline to provide them. You will filter out the bidders you most wanted.
Separate mandatory requirements from rated ones
Every requirement in your document is doing one of two jobs. A mandatory requirement is pass or fail, and failing it removes the bid from consideration. A rated requirement earns points on a scale. Mixing them is how good bidders get disqualified on a technicality and how weak bidders survive on one.
Keep the mandatory list genuinely short and genuinely essential: insurance levels, legal capacity to contract, the accessibility standard, data residency if it applies to you. Everything else should be rated. A common and avoidable mistake is making a specific number of years in business or a specific client sector mandatory, which excludes strong specialist firms for no benefit.
Publish the evaluation criteria and their weights
State how you will score submissions and what each element is worth. Bidders write to the criteria, so publishing them raises the quality of what you receive. Withholding them produces proposals that guess at your priorities and usually guess wrong.
If price is weighted at sixty percent, say so. A firm that cannot win on those terms will decline, which saves everyone a week. And if you intend to shortlist and interview, say that too, along with how many firms you will invite and roughly when.
Say what the contract will look like
Commercial terms belong in the RFP, not in a negotiation after selection, because they change what a firm is willing to charge. Four in particular:
- Who owns the work. You should own the custom code, the design files and the content outright on final payment. Say so. If a bidder intends to license you a proprietary platform instead, you want to know that before you score them, not after.
- Portability. Can you take the site to another host or another supplier without rebuilding it? A site you cannot leave is a site you will pay to leave eventually.
- Payment schedule. Tie payments to milestones with acceptance criteria rather than to dates.
- Warranty and support. How long after launch are defects fixed at no charge, and what counts as a defect rather than a new request.
Give a timeline that is real
Three weeks from release to submission is a working minimum for anything substantial, and a two-week window over a holiday period will cost you your strongest bidders. Include a written question period with answers circulated to everyone, which removes the assumption gaps that cause price variance.
And state your target launch date along with what is driving it. A date tied to a legislative deadline or a funding cycle is a constraint a bidder can plan around. A date with no stated reason gets treated as negotiable, and it will be.
A structure that works
Most of what makes an RFP effective is ordering. This outline covers everything above and rarely needs to run past fifteen pages:
- Who you are, and who the site serves.
- Why you are doing this now, in operational terms.
- What the project has to achieve, stated as outcomes.
- Current state: platform, page and document counts, integrations, languages, hosting, analytics access.
- Scope, including what is explicitly out of scope.
- Constraints: accessibility standard, security or data residency requirements, brand guidelines, anything you cannot change.
- Budget range and payment approach.
- Timeline, including the question period and the decision date.
- What to submit, kept short.
- Mandatory requirements, then rated criteria with weights.
- Contract terms: ownership, portability, warranty, support.
- Who to contact, and how questions are handled.
Where to post it
Public sector buyers in Canada generally have to post through the applicable tendering system, such as SEAO in Quebec, BC Bid in British Columbia, or MERX and the provincial portals elsewhere. Those systems reach firms that monitor them professionally, which is a mixed blessing: you get volume, and much of it is generic.
Private and non-profit buyers are under no such obligation, and are usually better served by inviting four or five firms directly. A short invited list produces better proposals than an open call, because each bidder knows their odds are reasonable and invests accordingly.
The five mistakes worth avoiding
- Specifying the solution instead of the problem.
- Hiding the budget.
- Omitting the content and document volumes.
- Requesting speculative design.
- Leaving out what happens after launch, which is where most of the site’s life is spent.
An RFP written this way is shorter than the one you were planning, takes less time to evaluate, and produces proposals you can actually place side by side. That is the entire point of the exercise.
If you are preparing an RFP and want to know how a studio reads it, our WordPress development in Canada page sets out how we scope, price and hand over work.