An RFP is a question you are asking several companies at once. If the question is fuzzy, every answer will be fuzzy too — long on adjectives, short on numbers, and impossible to compare side by side. If the question is precise, the proposals sort themselves: the serious agencies answer it, and the rest reveal themselves by not answering it.
This guide is written from the receiving end — the agency side of a website development RFP. What follows is what makes the difference between a document we can respond to properly and one where every bidder is guessing — plus a template you can copy and a scorecard for evaluating what you get back.
What an RFP is actually for
A request for proposal does three jobs at once. It tells agencies whether the project is a fit for them, so the wrong ones can bow out early. It gives the right ones enough to estimate scope, effort and risk without a week of discovery calls. And it forces you to make decisions before you commit money — which is where most of the value is, whether or not you end up sending it.
That last point matters. If you cannot answer a question in the template below, that is not a gap in the document. It is a decision you have not made yet, and an agency's proposal will make it for you — usually in whichever direction is cheapest for them to build.
The nine things every website development RFP needs
1. Who you are, in one paragraph
Not your history. What you sell, to whom, and what the website has to do for that. "We are a regional HVAC company; the site's job is to turn emergency-repair searches into phone calls" tells an agency more than three pages of company background.
2. Why now
Something prompted this. The old site cannot be updated, the checkout loses orders, a rebrand landed, the team is moving to a new CRM. Name it. The trigger tells the agency what "success" means to you and what they must not break.
3. What the site must do — as outcomes, not features
Write the outcomes first: "a visitor should be able to get a quote in under two minutes without calling us." Then, separately, list any features you already know you need. Outcomes let an agency propose a better route than the one you imagined. A features-only list gets you exactly what you asked for, which is rarely what you wanted.
4. What exists today
Current platform, hosting, domain registrar, analytics, any integrations (CRM, payments, booking, inventory), and who has the logins. Include what must be migrated and what can be left behind. If content is coming over, say how many pages, whether it needs rewriting, and who is doing that writing — late content is the most common reason a launch slips, and the RFP is where responsibility for it gets assigned.
Then the requirements that are not features but shape every estimate: a CMS preference (or an explicit "open to recommendation"), hosting constraints, the accessibility standard you need to meet, any privacy or compliance obligations on the data the site collects, what "fast enough" means for your audience, which browsers and devices must be supported, and whether your team needs training to run the site afterwards. An agency that does not see these will assume the cheapest answer to each.
5. Scope boundaries
State what is in and, just as importantly, what is out. Copywriting, photography, logo work, ongoing maintenance, SEO, paid ads — each of these is a separate discipline, and an agency will either quietly include it (and price it) or quietly exclude it (and you will find out later). Decide, and write it down. If you are unsure, say "we would like these quoted as optional line items."
6. Budget — a range, not a secret
Agencies price to the budget. If you withhold it, you get proposals spread across an order of magnitude, most of them for a project you would never buy. A range ("we expect this to land between X and Y; tell us what changes at each end") produces proposals you can actually compare, and it screens out mismatches before anyone spends a day writing.
7. Timeline, with the real constraints
A launch date is only useful with the reason behind it: a trade show, a season, a contract ending. Say which dates are fixed and which are preferences. And be honest about your own availability — a four-week build needs someone on your side who can review work and make decisions within a day or two.
8. How you will decide
List your evaluation criteria and their weights before you read a single proposal. This is the section RFPs most often leave out, and it is the one that stops the decision being made on gut feel and the nicest-looking PDF. A simple version is in the scorecard below.
9. Logistics
Submission deadline, format, a named contact, whether there is a question period, when you will decide, and when the work would start. If you plan to shortlist and interview, say so — it changes how much an agency invests in the written proposal.
What to leave out
Boilerplate legal terms. Put them in the contract, not the RFP. A twelve-page terms appendix signals a procurement process that will be as heavy as the document, and good small agencies will pass.
A page-by-page sitemap you have not tested. Share the pages you know you need; let the agency propose structure. If you have already decided the entire architecture, you are hiring a builder, not a partner — which is fine, but say that instead.
Speculative work. Asking for mock-ups or strategy documents as part of the proposal means the agencies who take it seriously do unpaid work, and the ones who do not send stock decks. Ask for relevant past work and a written approach instead. If you want to see how an agency thinks, pay for a short paid discovery engagement with your top two.
Every stakeholder's wish list. Consolidate before you send. Contradictory requirements from different departments are the first thing an experienced agency notices, and they price the friction in.
A template you can copy
Replace everything in brackets. Delete sections that do not apply rather than leaving them vague. The template splits the nine items above into eleven sections — it adds a list of what you want in the proposals, and separates the evaluation criteria from the process logistics — because those are the parts agencies most often have to ask about.
WEB DEVELOPMENT RFP — [Company name]
Issued: [date] Proposals due: [date] Decision by: [date] Contact: [name, email]
1. ABOUT US
[One paragraph: what you do, for whom, and what the website has to accomplish.]
2. WHY THIS PROJECT, WHY NOW
[The trigger. What is broken, changing, or being launched.]
3. OUTCOMES
The new site must make it possible for:
- [a visitor type] to [do a thing] [measure of ease/speed]
- [a visitor type] to [do a thing] [measure]
- [our team] to [update/manage something] without [constraint]
4. KNOWN REQUIREMENTS
- Must integrate with: [CRM / payments / booking / other — name the products]
- Must support: [languages, accessibility standard, regions, devices]
- Must migrate: [approx. page count, media, user accounts, order history]
- Must not change: [anything that has to survive the rebuild]
- CMS: [a named platform / open to recommendation / no CMS needed]
- Hosting: [our environment and constraints / open to recommendation]
- Accessibility: [the standard and level you need to meet, if any]
- Privacy and compliance: [regulations that apply to the data the site collects]
- Performance: [what "fast enough" means for your audience and devices]
- Browsers and devices: [what must be supported; what can be dropped]
- Training and documentation: [who needs to be able to run the site afterwards]
5. CURRENT STATE
Platform: [ ] Hosting: [ ] Domain registrar: [ ] Analytics: [ ]
Who holds the logins: [ ] Known problems with the current site: [ ]
6. SCOPE
In scope: [design, development, migration, training, launch]
Out of scope: [copywriting, photography, branding, ongoing SEO, paid media]
Content: [who writes new copy, who migrates existing content, and what happens
to the schedule if content arrives late]
Please quote as optional line items: [maintenance, hosting management, other]
7. BUDGET
We expect the core project to fall between [low] and [high]. Please tell us
what you would recommend at each end of that range and what changes between them.
8. TIMELINE
Target launch: [date] — [fixed / preferred] because [reason].
Our side can review and approve work within [N] business days.
9. WHAT TO INCLUDE IN YOUR PROPOSAL
- Your understanding of the project and your proposed approach
- Two or three relevant examples of past work, with what you were responsible for
- Team: who would work on this and their roles
- Timeline with milestones and what you need from us at each
- Pricing: fixed fee or estimate, what is included, payment schedule
- Assumptions and exclusions
- What happens after launch: warranty, support, handover
10. HOW WE WILL EVALUATE
[Your evaluation criteria and their weights — see the scorecard in this guide.]
11. PROCESS
Questions accepted until [date]; answers shared with all bidders.
Shortlisted agencies will be invited to a [30/60]-minute call the week of [date].Scoring the proposals you get back
Weight these before proposals arrive, then score each one on the same sheet. Adjust the weights to your situation; the point is that they are written down first.
- Understanding of the problem (25%) — Did they restate your outcomes in their own words, and did they get it right? A proposal that leads with their process instead of your problem has not read the RFP.
- Relevance of past work (20%) — Similar industry, similar integrations, or similar scale. Prettiness is not relevance.
- Approach and team (20%) — Is there a named person who will actually do the work? Do they explain how, not just that?
- Price and value (15%) — Within range, with clear assumptions. The cheapest proposal is only a bargain if its exclusions do not contain the expensive parts.
- Timeline realism (10%) — Does it include your review time? A schedule that assumes same-day approvals from you is a schedule that will slip.
- After launch (10%) — Warranty period, documentation, who owns the code and accounts, what support costs.
A proposal that scores well everywhere but leaves you unable to answer "who owns the code when this is done?" is not finished. Ask.
Questions to ask on the call
- Walk me through how you would handle [your hardest requirement].
- What in this RFP worries you?
- What would you cut if the budget came in at the low end?
- Who is my day-to-day contact, and what is their capacity right now?
- Show me a project that went wrong and what you changed afterwards.
The second question is the useful one. An agency that says "nothing" has either not read it closely or is not going to tell you when something goes wrong later.
Before you send it
- Every outcome in section 3 has a way to measure it
- Budget is a range with a reason for the ends
- Out-of-scope list exists and someone senior has signed off on it
- Evaluation weights are written down and shared internally
- One named contact who can answer questions within two business days
- The deadline gives agencies at least two weeks — good ones are busy
If the document takes you a full day to write, that is a day well spent. The decisions you make in it are the ones that would otherwise be made for you, at your expense, halfway through the build.
If you are putting one together and would rather talk it through than write it alone, send us what you have so far. For a sense of how we work once an RFP turns into a project, see our web design service and the process from brief to launch.