Web development RFP template
The full RFP structure for when procurement requires one — with the honest note that a six-question brief usually beats a forty-question document.
The truth first: for most businesses a six-question brief beats a forty-question RFP — it gets more replies, better replies, and faster. But some clients, procurement teams and larger organisations require a formal RFP, and when they do, you need a structure that reads competent without padding. This is that structure: the sections a serious reviewer expects, each phrased so you can fill it without inventing requirements you do not have. Honest gaps ("to be confirmed", "not yet decided") read better than fabricated detail — reviewers have seen both.
The fields, with guidance
Project context
The plain-language background that lets a vendor understand what this is before the technical detail.
Example: We publish 60+ educational guides and take enquiries via a contact form; the current site is a 2019 theme build we have outgrown.
Goals & success metrics
What changes when this succeeds, and how you will measure it. Specific metrics separate a real RFP from a cut-and-paste one.
Example: Qualified enquiries up 40% within six months, measured in GA4 form events; mobile page speed green on Core Web Vitals.
Scope
Pages, features, integrations as a list. State what is explicitly out of scope too — it is the cheapest clause in the document.
Example: Six pages, CMS, two intake forms routed to sales, blog; out of scope: copywriting, paid ads, ongoing SEO.
Technical constraints
Platform, hosting, tools, brand, accessibility and security requirements — anything locked before the build.
Example: Preference for WordPress; current host must stay; WCAG AA; brand guidelines provided on award.
Budget band
A real range you can spend. State it: it filters out vendors who cannot work at your level and gets you proposals you can compare.
Example: $6,000–9,000 inclusive of content support and launch.
Vendor questions to require
Demand the answers that expose real capability: process, ownership, references, exit terms.
Example: How do you handle scope changes? Who owns the code and when? Show a live site running a real business.
Evaluation criteria
How you will score proposals — the columns you will compare, not vague enthusiasm.
Example: Written spec quality 30%, price 25%, experience with this type of site 25%, process and terms 20%.
Timeline
Launch date, the milestone gates, the decision and feedback schedule, and what slipping a deadline costs.
Example: RFP closes in 10 days, proposals due in 14, decision in 21, site live by 1 October.
Copy this block
REQUEST FOR PROPOSAL — [PROJECT NAME]
1. PROJECT CONTEXT
Who we are and what this is for:
Current state (site, systems, history):
2. GOALS & SUCCESS METRICS
Business outcome:
Metric and how it will be measured:
3. SCOPE
In scope (pages / features / integrations):
Explicitly out of scope:
4. TECHNICAL CONSTRAINTS
Platform / hosting / tools:
Brand / accessibility / security:
Locked decisions:
5. BUDGET BAND
Range we can spend:
What must be included in that range:
6. VENDOR QUESTIONS (responses required)
- How do you handle scope changes mid-project?
- Who owns the code, and when?
- Show a live site running a real business.
- What is in your standard contract?
- How do you back up and test restores?
7. EVALUATION CRITERIA
How proposals will be scored:
Weighting:
8. TIMELINE
RFP close / proposals due / decision / launch:
Milestone gates:
Plain text on purpose — pastes cleanly into email, docs and project tools.
Fill the honest parts, leave the rest marked "to be confirmed", and you have a document that reads professionally without inventing requirements. For the version that gets the best replies, the six-question brief is usually it — and when you are ready, send the brief here and get a scoped quote back within two business days.
Quarterly, and only when the numbers move
Get the rate report before you negotiate.
Updated rate bands across the major stacks and regions, plus what changed and why. No other email.