The short answer
A good website RFP explains the problem, not just the features: who you are, what the new site must achieve and how you will measure it, what exists today, the scope, technical and accessibility requirements, a budget range, the timeline, what responses should contain and how they will be scored. Publish the budget and invite few vendors.
A request for proposal is the formal version of a project brief. It exists so that an organisation can compare vendors fairly and show that it did. Written well, it attracts thoughtful proposals that are easy to compare. Written badly, as a long feature list with no budget and a two-week deadline, it attracts boilerplate from firms that answer every RFP and silence from the studios you actually wanted.
This guide is written for US organisations running a website redesign RFP, with figures in US dollars, though the structure works anywhere.
Do you actually need an RFP?
You need an RFP when your rules require competitive bids: public agencies, school districts, universities, many nonprofits and grant-funded organisations, and companies with procurement departments. If you are a small or mid-sized business free to choose, a short brief and conversations with three or four studios will usually produce a better result, faster.
The difference is mostly formality. A brief invites a conversation; an RFP sets rules for a competition. If you do not need the rules, the brief is the better tool, and our website brief template covers it. The rest of this guide assumes you do.
What a website redesign RFP should contain
A complete website RFP has twelve parts: organisation overview, goals and measures, the current site with its numbers, audiences and their key tasks, scope, technical and accessibility requirements, content and migration, budget, timeline, response requirements, evaluation criteria and contract terms. Each section below explains what to write and the common mistake to avoid.
1. About your organisation
Who you are, what you do, who you serve, and anything about your situation that shapes the project: a merger, a new strategy, a funding cycle, a rebrand. One page is plenty. Vendors need context, not your full history.
2. Goals and how you will measure them
The two to four outcomes the new site must deliver, each with a measure. More qualified enquiries, more online donations, fewer support calls, more applications, better accessibility compliance. This is the section that separates useful proposals from generic ones, because it tells vendors what to optimise for.
3. The current site, with numbers
Platform, number of pages, monthly visitors, top pages, conversion figures, and what works and does not today. Attach analytics summaries if you can. Vendors who know the starting point can estimate migration and redirect work honestly.
4. Audiences and their key tasks
The main groups who use the site and the tasks each comes to complete: find a service, check eligibility, apply, donate, book, download a document, contact a person. Prioritise them. A ranked list of tasks is more useful to a designer than a list of pages.
5. Scope
Approximate page count and number of distinct page types, required features such as search, forms, events, donations, member areas or multilingual content, and integrations with your CRM, payment, donation, email or booking systems. Mark each as required or optional, so vendors can price the core and the extras separately.
6. Technical, accessibility and security requirements
The content management system, if you have a preference or a constraint, hosting expectations, security and privacy requirements, and accessibility. Name a standard, such as WCAG 2.2 AA. State and local government bodies should note the Department of Justice's 2024 rule under ADA Title II, which sets WCAG 2.1 AA as the standard for their web content, with compliance dates in 2026 and 2027 depending on size. Federal agencies follow Section 508.
7. Content and migration
How much existing content moves across, who writes new content, who supplies photography, and whether the vendor should handle migration, redirects and content entry. Content is the most common cause of delay, so be honest about what your team can produce.
8. Budget
A range for design and build, with ongoing hosting and support listed separately. For a full-service agency redesign, our US and UK website cost guide puts typical build costs at $20,000 to $35,000 or more, so a range such as $20,000 to $35,000 would be a realistic thing to publish. Publishing a range is the single biggest improvement most RFPs could make.
9. Timeline
Key dates for the RFP itself and the desired launch window, plus any fixed deadline that cannot move, such as an event, a fiscal year end or a compliance date. Distinguish hard deadlines from preferences.
10. Response requirements
What each proposal should include and the page limit. Ask for the approach to your specific goals, relevant past work, the named team, a timeline, an itemised cost, references and assumptions. Avoid asking for speculative designs; see the mistakes section below.
11. Evaluation criteria
How proposals will be scored, with weights. Publishing the criteria produces better-targeted responses and makes your decision easier to defend.
12. Contract terms
Your standard terms, plus the points that matter most for websites: ownership of the domain, code, design files and content; hosting account ownership; accessibility obligations; warranty period; and how changes in scope are handled. The clauses worth insisting on are in our web design contract checklist.
A copyable website RFP outline
Use the outline below as the skeleton of your document. Each item says what that section should contain; write it in your own words, keep the order so vendors can find things quickly, and attach supporting material, such as analytics exports, brand guidelines and sitemaps, as appendices rather than pasting it into the body.
- Summary. One paragraph naming your organisation, the website being redesigned, the proposal deadline and the budget range.
- About us. Your mission, the audiences you serve, your size, and any context that shapes the project, such as a merger, a new strategy or a rebrand.
- Project goals. Two to four outcomes the new site must deliver, each with a measure and a target.
- Current website. The platform, number of pages, monthly visitors, the tasks people come to complete and the known problems, with an analytics summary attached.
- Audiences and key tasks. A ranked list of the groups who use the site and what each needs to do on it.
- Scope. The approximate page count and page types, features and integrations, each marked as required or optional.
- Requirements. Content management system, hosting, security and privacy expectations, and the accessibility standard, such as WCAG 2.2 AA.
- Content and migration. What existing content moves across, who writes new copy, who supplies photography and who handles redirects.
- Timeline. The dates of the RFP process, the launch window you want and any deadline that cannot move.
- Proposal requirements. What each response must include, such as the approach, relevant work, the named team, a timeline, an itemised cost, references and assumptions, and the page limit.
- Evaluation. The scoring criteria and their weights, and how the shortlist and interviews will work.
- Terms. Ownership of the code, design files and content, hosting, accessibility obligations, the warranty, the change process, and your standard contract as an attachment.
- Contact and questions. A named contact, how and by when vendors can submit questions, and when answers will be shared with every bidder.
How to score the responses
Score every proposal against the same published criteria, with weights agreed before the proposals arrive. Price should matter but rarely dominate: understanding of your goals, relevant experience and the quality of the team predict a good website better than the lowest bid. Interview the top two or three before deciding.
| Criterion | Suggested weight | What a strong response shows |
|---|---|---|
| Understanding of goals and audiences | 25% | Responds to your stated goals and tasks specifically, and asks sharp questions |
| Relevant experience and work | 20% | Comparable projects with outcomes, not just screenshots |
| Approach and process | 15% | A clear plan for research, content, design, build, testing and launch |
| Team | 10% | Named people who will do the work, with their roles |
| Accessibility and technical quality | 10% | Specific commitments on standards, performance and security |
| Cost and value | 15% | Itemised, within range, with assumptions stated |
| References | 5% | Clients who confirm the vendor delivered what was promised |
The weights are a starting point, not a rule; adjust them to your priorities, but fix them before you read the first proposal.
A realistic RFP timeline
From issuing the RFP to signing a contract usually takes five to eight weeks: two to four weeks for vendors to respond, with a question deadline in the middle, one to two weeks to score and shortlist, and one to two weeks for interviews, references and negotiation. Build that into your launch date before you start.
| Step | Typical timing |
|---|---|
| RFP issued | Week 0 |
| Deadline for written questions | Week 1 to 2 |
| Answers shared with all bidders | Within a few days of the question deadline |
| Proposals due | Week 2 to 4 |
| Scoring and shortlist | 1 to 2 weeks after the due date |
| Interviews and references | 1 week |
| Decision and contract | 1 week |
The project itself follows. For a site of five to eight pages, design and build typically take six to ten weeks; larger corporate and institutional sites take longer. How long it takes to build a website breaks it down by type.
Mistakes that make good studios decline
Strong studios receive more RFPs than they can answer, so they choose. They tend to decline RFPs with no budget, a response window under two weeks, requests for free design work, dozens of invited bidders, a feature list with no goals, or signs that the winner has already been chosen. Avoiding these widens your field considerably.
- No budget. Vendors cannot scope sensibly, so the careful ones decline and the rest guess.
- Speculative design requests. Asking for mockups before a contract asks for unpaid work and produces designs made without research. Ask how they would approach the problem instead.
- A very short window. Two weeks or less mostly excludes studios with full schedules.
- A feature list without goals. Vendors can only price what you listed, not propose what would work better.
- Too many bidders. When forty firms are invited, the odds do not justify a serious proposal.
- Unanswered questions. Not sharing answers with all bidders makes proposals impossible to compare.
Considering studios outside the US
Many organisations now include international studios in their RFPs, for depth of skill as much as for cost. If your rules allow it, ask for overlapping working hours, a named project lead, US references, clarity on data handling and contracts under a jurisdiction you accept. Judge the work and the process, not the location.
We have written a practical guide from the client's side: hiring an overseas web design team. If donations are central to your site, donation pages that convert is worth reading before you write the scope.
Where we fit
studiokalex is a design and engineering studio in New Delhi that works with clients worldwide. If you are issuing a website RFP and want a proposal that responds to your goals rather than to a template, send it to us; if you are unsure whether you need one at all, we will give you a straight view.
See our web design page, or get in touch.