Direct answer: most web development RFPs we receive are missing the questions that actually make proposals comparable. This template — based on 12+ years of seeing what works — gives you 14 sections plus a sample quotation table and a scope-of-work agreement starter. Use it to make agency proposals apples-to-apples instead of "$5K vs $50K and we have no idea why."
The 14 sections every web development RFP should have
1. Project overview (1 paragraph)
What the business does, what the website is meant to accomplish, who the target audience is. Not buzzwords — concrete.
2. Current state
Existing site URL if any. Current platform (WordPress 6.x, Shopify Basic, custom Laravel, etc.). Why you are commissioning a new build or a migration.
3. Goals + success metrics
What does "success" look like 6 months post-launch? Concrete: "increase organic traffic from 2,000 to 8,000 sessions/month" beats "improve SEO."
4. Scope inclusions
Every page you expect on the new site, with a 1-line description each. If you have a sitemap, attach it.
5. Scope exclusions
What you explicitly do NOT want. "We do not need e-commerce." "We do not need a blog." Prevents proposals padded with features you do not want.
6. Functional requirements
Auth? Booking? Multi-language? Integrations (CRM, ordering, payment)? List each as a bullet with priority (must-have, should-have, nice-to-have).
7. Non-functional requirements
Performance targets (Lighthouse mobile ≥ 90), accessibility (WCAG 2.2 AA), browser support, mobile breakpoints, security baseline.
8. Tech stack constraints
Preferred or required technologies. If your in-house team is python-fluent, mention it — affects who can maintain the site after handoff. If you are migration-locked to WordPress, mention it.
9. Timeline + key dates
Target launch date. Any hard constraints (event, fiscal year, product launch). Discovery → design → build → QA → launch phases with rough dates.
10. Budget range
Most CFOs / procurement leads want to hide this. Don't. Sharing a range ($50K-$80K, $100K-$150K) saves agencies from quoting you something you can't afford and makes proposals comparable.
11. Deliverables expected
Working URL. Source code repository (in your GitHub). Design files (Figma). Hand-off documentation. 30-day post-launch support. Be specific.
12. Vendor questions
Specific questions you want each vendor to answer in their proposal. Sample: "Who specifically will write the code? Will they change mid-project? What is your post-launch support model?"
13. Selection process
How will you decide? "We will review proposals on [date], shortlist 3 for live calls on [date], select by [date], and sign by [date]." Sets expectations.
14. Submission instructions
Email + PDF preferred. Confidential? NDA available on request. Deadline.
Sample quotation table (what every proposal should answer)
| Section | What the vendor should include |
|---|---|
| Project cost | Total fixed-price, not hourly. Itemised by phase (discovery / design / build / QA / launch). |
| Currency + payment | USD or AED. 50/50 split typical. SWIFT or Wise. |
| Calendar dates | Phase 1 ends [date], Phase 2 ends [date], etc. Not "Week 3" — actual dates. |
| Team | Named project lead, named developer(s), with LinkedIn URLs. |
| Change order pricing | The rate at which post-SOW changes are quoted. Should not be 2x the project rate. |
| IP transfer | When does code ownership transfer? On final payment is standard. |
| Post-launch support | Days of bug-fix coverage included. After that, what is the maintenance option? |
| Tech stack rationale | Why this stack vs alternatives, in 1-2 sentences. |
| Lighthouse target | Specific number committed at launch. |
| References | 2-3 recent client URLs + contact for reference call. |
Web Development Agreement basics
The agreement (or "scope of work" attached to your MSA) should cover:
- IP transfer clause — code, design files, hosting accounts, domain, third-party API keys all transfer at final payment. No "perpetual licence" trap.
- Change order pricing — same hourly rate as the original project, not double. Quoted in writing before any out-of-scope work begins.
- Definition of "done" — explicit list of delivery criteria. Lighthouse score, schema validation, accessibility AA, working contact form, etc.
- Confidentiality / NDA — both directions; mutual or one-way per your preference.
- Indemnification — limited to project value (standard); excluding gross negligence + IP infringement.
- Governing law — your state if US client (NY, CA, TX common); UAE if regional.
We share a sample MSA + SOW template on request after a kickoff call.
Red flags in agency responses
Walk away if you see:
- "We'll figure out the details after kickoff" — no SOW = unmanaged scope = budget overrun.
- "We retain rights to the code" — vendor lock-in pattern. Insist on full transfer.
- Hourly billing with no estimate — you carry all overrun risk. Fixed-price reverses the incentive.
- "Standard agency hourly rate" with no breakdown — fight this. Quote-by-phase prevents surprises.
- "We can start tomorrow!" — they have no pipeline. Probably under-staffed. Real agencies have a queue.
What we put in our proposals
Our proposals to RFP-stage clients always include:
- Direct answer to every RFP question (no "we offer comprehensive web solutions" filler)
- Itemised cost by phase in USD
- Calendar dates, not "weeks"
- Named team with LinkedIn URLs
- Change-order pricing structure
- Sample SOW redacted from a recent project (on request, under NDA)
- 2-3 recent client references with contact information
If we are not chosen, we ask for feedback. The win rate on RFPs where this template is followed is meaningfully higher than the "everyone's proposals look the same" baseline.
If you are about to send an RFP, submit a brief and we will respond with this template structure. Or read how to choose a web design agency for the 12 vetting questions to ask each vendor on the shortlist.