A website redesign RFP decides the quality of the bids before any firm reads it. Give bidders the facts and they all price the same project. Leave gaps and each one prices its own guess, adds a margin for the risk and plans to recover the rest in change orders.
Below is what to put in the document, and an outline that keeps it under fifteen pages.
Decide what the document is for
If you could describe the finished site down to the last page, you would hire a contractor at a fixed price. You are writing an RFP because you can’t, and because you want a partner who has solved a problem like yours before. So the document describes the problem and its limits, then asks each firm how it would approach a website redesign like yours.
Watch for requirements that quietly choose the solution: a named plugin, a fixed page count, a menu drawn in advance. Each one takes away a decision you were paying an expert to make. The proposals come back identical except for the price.
Start with what is going wrong
The first section explains why you are doing this now. “Our site is outdated” tells a bidder nothing. Sentences like these tell them a lot:
- Staff can’t publish a news item without calling a developer.
- The forms don’t work on a phone.
- The French section hasn’t been updated in two years.
- Site search sends people to the wrong department.
- The site failed an accessibility review.
With facts like these, a bidder can tell you which of your problems is the expensive one. That is the most useful thing a proposal can do, and a feature list will never get you there. If you are still making the internal case for a redesign, these eight signs help you collect the evidence.
Give bidders the facts they can’t guess
When two bids for the same RFP are far apart, the firms have usually filled the same gaps with different assumptions. Close the gaps and the numbers move closer together.
- Size. The number of pages and the number of documents (PDFs, forms, reports). Count them with a crawl of the current site. These two numbers move a quote more than anything else in the RFP.
- The current platform, its version, and whether the content can be exported.
- Integrations, by name. Which systems, which vendors, and whether they have documented APIs.
- Languages, and how closely the versions must match. A French site that mirrors every English page is a different job from a French summary.
- The accessibility standard, with a version number. Nobody can score “accessible”. Anyone can score “WCAG 2.2 Level AA”.
- Who writes the content. Say whether the text is reused as is, rewritten by your team or written by the firm.
- Hosting, and whether the winning firm takes it over or replaces it.
- Who decides. Name the person who approves and the steps to get there. A committee takes longer than one manager with authority, and bidders price that time.
Publish the budget range
Many buyers hold the budget back, hoping firms will compete on price. What comes back are proposals sized for different projects: one firm scopes a refresh, another a full rebuild, and nothing lines up. Firms whose minimum sits above your ceiling also lose a week on a bid that could never fit.
With a range on the page, every firm designs for the same envelope. You end up comparing approach and skill instead of who guessed your number best.
If you truly can’t publish a number, describe what the project is worth to you in outcomes, or ask for prices on two or three defined options. Either one gives bidders something to scope against.
Ask for four things
A long list of submission requirements favours firms with a proposal writer on staff. These four requests tell you more about how a firm actually works:
- How would you approach this project, and what would you do first? The order a firm chooses shows you how it thinks.
- Two comparable projects, and what went wrong on each. Every firm has references. A firm that describes a real problem and how it handled it is showing you what working together will be like.
- Who will do the work, by name, and how much of their time is available. Trouble often starts when the people who pitched hand the project to people you never met.
- What happens after launch, and what it costs. A firm with no clear answer hasn’t planned for the years you will spend with the site.
Leave out free design work. Mockups made without research tell you little, and experienced firms often refuse to make them, so a spec-work requirement screens out the bidders you most wanted.
Separate mandatory requirements from rated ones
Each requirement does one of two jobs. A mandatory one is pass or fail: miss it and the bid is out. A rated one earns points on a scale. Mix the two and a strong bidder gets disqualified on a technicality while a weak one survives on another.
Keep the mandatory list short: insurance, the legal capacity to sign, the accessibility standard, and data residency if it applies to you. Rate everything else. Making ten years in business or experience in your exact sector mandatory shuts out specialist firms and gains you nothing.
Publish how you will score the bids
List the criteria and what each one is worth. Firms write to the criteria, so publishing them improves what you receive. Without them, bidders guess at your priorities, and the guesses are often wrong.
If price counts for sixty percent, say so. A firm that can’t win on those terms will step aside and save everyone a week. If you plan to shortlist and interview, say how many firms you will invite and roughly when.
Say what the contract will look like
Commercial terms change what a firm charges. Leave them for a negotiation after selection and the prices you compared were for a different deal. Put these four in the RFP:
- Ownership. On final payment you should own the custom code, the design files and the content. Write that down. If a firm plans to license you its own platform instead, you want to know before you score the bid.
- Portability. Could you move the site to another host or another firm without rebuilding it? A site you can’t leave will cost you when you finally do.
- Payments. Tie them to milestones with acceptance criteria rather than to calendar dates.
- Warranty and support. How long after launch defects are fixed at no charge, and where a defect ends and a new request begins.
Give a timeline that holds
Allow at least three weeks between release and the deadline for any substantial project. Two weeks over the holidays will lose you your strongest bidders.
Set a period for written questions and send every answer to every bidder. Each answer removes an assumption that would otherwise show up as a price difference.
Give your launch date and the reason behind it. A firm can plan around a date tied to a legal deadline or a funding cycle. A date with no reason gets treated as flexible.
An outline for your RFP
Much of what makes an RFP work is the order of its sections. This outline covers everything above and seldom runs past fifteen pages:
- Who you are, and who the site serves.
- Why you are doing this now, in concrete terms.
- What the project has to achieve.
- The current site: platform, page and document counts, integrations, languages, hosting, analytics access.
- Scope, including what is out of scope.
- Constraints: accessibility standard, security or data residency, brand guidelines, anything that can’t change.
- Budget range and how you will pay.
- Timeline, with the question period and the decision date.
- What to submit, kept short.
- Mandatory requirements, then rated criteria with their weights.
- Contract terms: ownership, portability, warranty, support.
- Who to contact, and how questions are handled.
Where to post it
Public bodies in Canada usually have to publish through a tendering system: CanadaBuys for federal contracts, SEAO in Quebec, BC Bid in British Columbia, MERX and the provincial portals elsewhere. Firms watch these systems every day, so you will get plenty of responses, and many of them generic.
Companies and nonprofits have no such obligation. Inviting four or five firms directly usually brings better proposals than an open call. Each firm knows its odds are fair, and puts real time into the bid.
Five mistakes to avoid
- Describing the solution instead of the problem.
- Hiding the budget.
- Leaving out the page and document counts.
- Asking for free design work.
- Saying nothing about life after launch, where the site spends most of its years.
An RFP built this way is shorter than the one you were planning. It takes less time to evaluate, and the proposals it brings back can sit side by side.
Writing one now and wondering how a studio will read it? Our page on WordPress development in Canada shows how we scope, price and hand over a project.