Most website RFP templates are fill-in-the-blank documents. They give you the structure, tell you to insert your organization's name, and send you on your way. The problem is that structure alone doesn't produce a useful RFP.
I've received hundreds of RFPs over 25 years, and I can tell you that the ones built from generic templates all read the same: sleek, modern design, mobile-responsive, SEO-optimized. None of that tells me what the organization actually needs.
What follows is a website RFP template that does something different. For each section, I'll explain not just what to include but what vendors actually pay attention to, what we skim past, and what makes us decide whether to invest the 25-plus hours it takes to write a thoughtful response.
That investment matters: according to Responsive, 40% of vendors say the RFPs they receive are poorly written, and agencies respond to only about 55% of the RFPs that cross their desks. The rest aren't worth the effort. If you're preparing to hire a web developer or agency, this is the website RFP template that will get you proposals worth comparing.
If you're looking for broader guidance on the RFP process itself, start with our complete guide to writing a website RFP. This template is the practical companion to that guide.
How to Use This Website RFP Template
This is not a copy-paste document. If you copy this template word for word, swap in your organization's name, and send it to 15 agencies, you will get exactly the kind of generic proposals you're trying to avoid. The template is a thinking tool. It walks you through the decisions you need to make and the information your vendors need to respond accurately.
If you use these templates to guide your thinking, you're providing your vendor with the organized information they need to answer your RFP accurately. Accuracy is key to everyone being happy at the end of the project.
Pull more than one template if you want. Whether it's labeled a website proposal template, an RFP template for website projects, or something else, compare them. Use them to make sure you haven't missed anything. But the value isn't in the format. It's in whether you've done the work to describe what you actually need.
Here's why this matters from the vendor side: when I respond to an RFP, I'm filling my response with best practices, but if I miss the one thing the marketing director is looking for, I'm out. And that's usually what happens.
The review committee has its own motivation for wanting a new website. One person is focused on design, another on e-commerce, another on the members' area. Unless the RFP gives me enough information to hit all of those needs, I'm guessing. The more clearly you describe what matters to your organization, the more accurately every vendor can respond.
Ground Rules Before You Start
Target length for your finished RFP: 8 to 15 pages, plus appendices. That's long enough to communicate goals, scope, and constraints clearly, and short enough for vendors to read in 30 minutes and respond within a reasonable timeframe. Anything over 25 pages discourages qualified vendors from responding. Use appendices to support details such as sitemaps, brand guidelines, and analytics reports.
Who should be in the room when you write this: The people who will make the final decision, plus one person who uses the current website daily. Not a committee of 12. A small group that can speak to the organization's goals, its content challenges, and its technical pain points.
Send it to 4 to 6 pre-qualified vendors, not 40. Mass-distributing an RFP signals that you haven't done your homework on vendor selection and virtually guarantees that the best agencies will ignore it. NTEN calls this "RFP spam," and it's one of the top mistakes nonprofits make. Identify vendors you'd actually want to work with, review their portfolios, and then invite them to respond.
If you already know who you want, don't use an RFP as theater. This one matters. I've been burned several times when I later realized I was just the obligatory competing bid because the board requires three quotes. The organization already knew exactly who they were going to hire.
And I've seen what happens next: the organization collects all the bids, gathers up the good ideas and the pricing, and basically hands it all over to their vendor of choice, who then gets the courtesy of putting together a winning bid using everyone else's work. If your bylaws require competitive bids but you have a preferred vendor, be honest with yourself about the process. Vendors can feel when an RFP is a formality, and the good ones won't play along.
Section 1: Executive Summary
What it is: A one-page overview of your project. Think of it as the cover letter for your RFP.
What to include:
- Why you're doing this project now (the business driver)
- What success looks like in one or two sentences
- Your budget range
- Your target launch window
- How many vendors are you inviting to respond
What vendors read closely: Everything. This is the triage section. Experienced agencies receive dozens of RFPs and make a go-or-no-go decision within the first page. If your executive summary includes a budget range, a timeline, and a clear reason for the project, you've already separated yourself from most RFPs.
What vendors skip: Preamble. Don't spend the first paragraph explaining what an RFP is. The vendors know. Get to the point.
Example (Before)
"Our organization is seeking proposals from qualified vendors to design and develop a modern, responsive website that reflects our mission and values."
This tells me nothing. Every RFP says this. I have no idea what the project is, what it costs, or why it matters.
Example (After)
"The National Association of [Industry] is seeking proposals for a complete website rebuild to replace our current WordPress site, which was last redesigned in 2019. Our primary goal is to increase member engagement through a redesigned member portal with single sign-on integration to our AMS (iMIS). Budget range is $75,000 to $100,000. We plan to select a vendor by Q3 2026 and launch by Q1 2027. This RFP has been sent to five pre-qualified agencies."
Now I know exactly what we're talking about. I know the CMS, the integration complexity, the budget, and the timeline. I can make an informed decision about whether this is a project my team should pursue.
Section 2: Organization Background
What it is: A brief description of who you are, what you do, and why it matters for this project.
What to include:
- Mission and purpose (two to three sentences, not a full page)
- Organization size (staff, members, budget range if relevant)
- Key audiences you serve
- Relevant organizational structure (chapters, affiliates, departments)
- Decision-making context (who approves the final product)
What vendors read closely: Organization size and complexity. An association with 50,000 members and a chapter structure presents different challenges than a 10-person nonprofit with a $500K annual budget. Vendors need this context to assess whether they have relevant experience and the right team for the project.
What vendors skim: Lengthy founding stories and mission statements. Keep this to half a page. If your organization was founded in 1952, that's interesting, but it doesn't help me price your website. I need to understand your scale, your audience, and your operational complexity.
A Note on Decision-Making
Tell us who decides. How many stakeholders need to approve designs? Who has final say?
Vendors factor governance complexity into both pricing and timeline. A project in which one director can approve a homepage comp is fundamentally different from one in which a seven-person board committee reviews every deliverable. Be upfront about your process because it directly affects how long the project takes and how much it costs.
Section 3: Project Goals and Objectives
What it is: The most important section of the entire RFP, and the one most organizations get wrong.
What to include:
- Three to five measurable goals with clear success criteria
- What "done" looks like for each goal
- How will you measure success after launch
- What's driving the project (not just "we need a new website" but the underlying business need)
What vendors read closely: This section determines our strategic approach, staffing, and pricing. Clear goals with measurable outcomes enable differentiated, creative proposals. Vague goals lead us to generic responses because we have nothing specific to solve.
I've seen this confirmed across the industry: a page or two describing objectives is far more useful than pages of requirements tables. Spend more space on what you want to achieve than on how you think it should be built.
What vendors skip: Laundry lists of aspirational features with no priority attached. If everything is a priority, nothing is.
Example (Before)
"We want a modern, user-friendly website that positions our organization as a leader in our field."
I've seen this sentence a hundred times. It doesn't mean anything actionable. What does "modern" look like to you? What does "user-friendly" mean for your specific audience? How would you know if you'd achieved it?
"Mobile-first design" and "built for SEO" are the same problem. These buzzwords show up in every nonprofit RFP. But when you look at a nonprofit's Google Analytics and fewer than 20% of their users are on mobile, "mobile-first" is wasted focus. Don't write buzzwords. Ask yourself what your users actually need to accomplish, and write goals around that.
Example (After)
"Goal 1: Increase online donations by 25% within 12 months of launch, measured against our current annual giving total of $180,000."
"Goal 2: Reduce support tickets related to finding information on the website by 40%, measured through our Zendesk tracking."
"Goal 3: Achieve WCAG 2.2 AA compliance across all public-facing pages, validated by automated and manual accessibility audit."
Those are goals I can build a strategy around. I know what to optimize for, what to test, and how we'll both know whether the project succeeded.
For more on how specific language changes the quality of proposals you receive, see our examples of effective vs. ineffective RFP language.
Section 4: Target Audience
What it is: Who uses your website and what they're trying to accomplish when they visit.
What to include:
- Primary audience (one or two groups, not five)
- What each audience is trying to do on the site
- Any behavioral data you have (analytics, surveys, support tickets)
- Secondary audiences, if relevant
What vendors read closely: Audience definition drives information architecture, UX decisions, and content strategy. Telling us that your audience is "the general public" is not helpful. Telling us that your primary audience is association members who need to access continuing education credits, and that your secondary audience is prospective members evaluating whether to join, is extremely helpful.
Why limiting matters: The best websites are clear about who they're primarily serving. If you try to design for five equally important audiences, you end up designing for none of them. Pick one or two primary groups and describe what they need to accomplish. Your vendor can help you figure out how to serve secondary audiences without compromising the experience for primary ones.
Section 5: Current Website Assessment
What it is: An honest look at where you are right now.
What to include:
- Current CMS and hosting environment
- Known pain points (what's broken, what frustrates your team)
- What's actually working well (preserve what works before rebuilding everything)
- Approximate traffic volume (monthly visitors, if you know)
- Any recent user feedback or analytics insights
- Link to the current website
What vendors read closely: CMS and hosting details, because they directly affect migration complexity. A site running on a custom-built CMS with 5,000 pages is a fundamentally different project from a 30-page WordPress site. Knowing the starting point prevents us from proposing solutions to problems that don't exist and helps us account for the real complexity of data migration.
What many organizations forget: Sharing what works. If your current site's blog drives significant traffic, or your resource library is heavily used, or your event registration flow works well, tell us. A good vendor will preserve what's working and fix what isn't. Assuming everything needs to be rebuilt from scratch is one of the most expensive mistakes in a website project.
Section 6: Scope of Work
What it is: A description of what you need built, organized by category or phase.
What to include:
- High-level deliverables: strategy and discovery, UX and information architecture, visual design, development, content, integrations, training, launch support
- Which items are must-haves versus nice-to-haves
- Any known features or functionality (member portal, e-commerce, event registration, donation processing)
- Content responsibility: who writes, who edits, who approves, who migrates
What vendors read closely: Feature requirements and integrations, because they have the largest impact on cost. A Salesforce integration can add $15,000 to $50,000 to a project. Single sign-on requirements may double the authentication budget. We need this information to price accurately.
Describe Outcomes, Not Solutions
"We need to showcase 200-plus member organizations with filtering by geography and issue area" is better than "we need a searchable directory with dropdown filters and a map integration using Google Maps API." The first tells us the problem. The second tells us how to solve it, which limits our ability to propose a better solution.
This is one of the most common mistakes in RFPs. Organizations prescribe solutions rather than describe problems.
When an RFP tells me the CMS, the page builder, the form plugin, and the caching plugin to use, it signals one of two things: either the organization has deep technical knowledge and has made deliberate choices (rare), or someone Googled "best WordPress plugins" and hardcoded the results into their requirements (common). The second scenario ties our hands and often leads to worse outcomes.
Content: The Section Everyone Forgets
Content is the single biggest variable in website project timelines. An RFP that details every technical feature but says nothing about content signals that the organization hasn't thought through the hardest part of the project.
Address these questions in your scope:
- Who is writing the content? Your team, the vendor, or a third party?
- How many pages of content need to be migrated from the current site?
- Who reviews and approves content, and what's the expected turnaround time?
- Do you have a content style guide, or does one need to be created?
- Will you need ongoing content support after launch?
Projects where content responsibility is undefined are the ones that go over budget and behind schedule. Industry data suggests that projects with content-ready clients complete 30 to 40 percent faster than those where content is figured out along the way.
If your vendor is responsible for content, scope it. If your team is responsible, commit to deadlines. If nobody has thought about it yet, say that, because it will affect the timeline.
Scope: Before and After
The difference between a scope section that doesn't work and one that does is where projects either succeed or fall apart.
Vague scope: "We are a membership organization, and we want our members to be able to sign in and access member-only material."
Defined scope: "We are a membership organization with three levels of members. We'd like members to log in to access directories, PDFs, and gated content, which may be restricted by membership level. Additionally, we would like our members to be able to pay their dues, track payments, and download previous year invoices."
The difference is that the second version is actually scoped. I know exactly what you want. I don't have to guess whether members can make donations or download receipts. Most clients assume it's obvious that a member area should handle payments, but not all membership organizations are dues-based. This is the information we need.
My advice is always the same: create a list, a set of bullet points, of everything the site needs to do. If it doesn't have a bullet, it's not considered in scope. There will always be a slight gray area, but the stronger this list is, the better the project will go.
When we win a new project, I start our discovery meetings by telling everyone in the room: this is your dream. What do you want this website to do? Inevitably, ideas come out that were never in the RFP. That's fine, and it's part of the process. But the more of those ideas you capture in the RFP upfront, the more accurately your vendor can respond to the things that actually matter to your team.
Section 7: Technical Requirements
What it is: The technical environment and integration requirements for the project.
What to include:
- CMS preference or openness to recommendations
- Required integrations (CRM, email marketing, payment processing, SSO, AMS)
- Hosting requirements or preferences
- Security and compliance needs (HIPAA, PCI, state privacy laws)
- Accessibility standards (WCAG 2.1 Level AA is the current standard)
- Note on accessibility: Most RFPs miss this entirely, but enforcement is accelerating fast. The DOJ's ADA Title II rule now requires compliance for state and local government web content, the EU Accessibility Act is in effect, and ADA lawsuits against nonprofits and associations continue to rise. If your RFP doesn't address accessibility, your vendor may not either.
- Any third-party platforms that must connect to the website
What vendors read closely: Every word. Technical requirements have the greatest impact on development costs and are the area where missing information causes the biggest budget surprises later.
CMS and Maintainability
If you have a CMS preference, state it. If you're open to recommendations, say that too. But avoid dictating a specific CMS and then specifying the theme framework, page builder, form plugin, and caching solution. That level of prescription limits vendor creativity and often reflects research that won't survive the discovery process.
What I care about when I read this section is whether the organization has thought about maintainability. Are they looking for a system that their marketing team can update without calling a developer? Do they want custom-built solutions or off-the-shelf tools? The answers to these questions tell me more about the project than a list of plugin names.
I look for whether an organization values ease of maintainability, both from an administrative and a technical perspective. The best RFPs ask vendors to consider the technologies and solutions they use so the resulting product has as low overhead and as much technical simplicity as possible. That signals a sophisticated client.
Section 8: Budget
What it is: What you're prepared to spend on this project.
What to include:
- A realistic range (for example, "$75,000 to $100,000" or "not to exceed $150,000")
- Whether the budget includes ongoing support and hosting or just the build
- If you genuinely don't know, say so and ask vendors to propose tiered options
- Whether the budget is funded (approved) or still being determined
Why This Section Matters More Than Any Other
I feel strongly about this. If you have a budget, share it. Here's my logic: if you tell me what you can spend, I'll tell you what I can do for that. If the project is compelling or high-value, or I personally connect with the mission, I might be willing to do a lot more for less. But I don't know any of that yet when I'm reading your RFP.
When you don't provide a budget, you're forcing vendors to take shots in the dark. You're essentially choosing the vendor based on whether they happened to hit your number, and that may not be your best vendor. A lot of really good vendors, myself included, will skip RFPs where it's clear the organization is shopping around without a defined budget.
Reference Points for Website Costs
According to industry surveys, the average cost of a website redesign is approximately $42,500. Most professional nonprofit and association websites fall in the $30,000 to $60,000 range. Complex sites with multiple integrations, member portals, or custom functionality can run $60,000 to $150,000 or more. These numbers aren't meant to set your budget for you, but they can help you calibrate whether your expectations and your budget are in the same ballpark.
Since the dawn of the internet, there's been this idea that if it's online or open-source, it should be free or cheap. Your website is a 24/7 window into your organization. For nonprofits and associations with membership portals, dues collection, and event management, this is not the place to cut corners.
A website that interacts with your membership and serves as the primary point of engagement is actually cheap when you consider the alternative. No human could match those touch points or deliver at that level of efficiency, and they would cost you far more.
If your organization's budget is genuinely below market rate, be upfront and honest about it. Don't promise a great portfolio piece. Don't promise your members will hire us. I value those promises at zero dollars. It just doesn't happen. Be honest about your constraints and look for someone who cares about your cause.
For a deeper look at budget considerations specific to mission-driven organizations, see our nonprofit website RFP guide.
Section 9: Timeline and Milestones
What it is: Key dates and the overall project cadence.
What to include:
- RFP response deadline
- Vendor selection date
- Desired project kickoff
- Target launch date
- Any hard deadlines (annual conference, fiscal year, campaign launch, board meeting)
- Any known periods when your team will be unavailable
What vendors read closely: Whether the timeline is realistic. A $150,000 website redesign with a 6-week timeline is a red flag. With a 6-month timeline, it's reasonable. The timeline determines whether a vendor has capacity and whether the project is feasible.
What many organizations miss: The RFP process itself takes time. From issuing the RFP to kicking off the project typically takes 9 to 18 weeks:
- 2 to 4 weeks for drafting
- 1 to 2 weeks for vendor Q&A
- 2 to 4 weeks for responses
- 1 to 2 weeks for evaluation
- 1 to 2 weeks for interviews
- 2 to 4 weeks for selection and contract negotiation
Factor that into your planning. Organizations routinely underestimate this window and then compress the build timeline to hit an arbitrary launch date. That compression leads to shortcuts, and shortcuts lead to problems.
Include any hard deadlines, but also be willing to discuss the timeline with your selected vendor. Some of the best project outcomes happen when the vendor can propose a realistic schedule based on the actual scope rather than working backward from an artificial date.
Section 10: Evaluation Criteria
What it is: How you will score and compare proposals.
What to include:
- Weighted criteria showing how proposals will be evaluated
- Common criteria: relevant experience (25%), proposed approach (25%), team qualifications (15%), cost (20%), cultural fit (15%)
- Whether there will be a finalist interview or presentation round
- How many vendors do you plan to select for the shortlist
What vendors read closely: The weighting tells us what you value. If cost is weighted at 50%, we know this is a price-driven decision, and we'll optimize accordingly. If approach and experience dominate, we invest more time in strategy and case studies. Transparency about how you'll decide helps vendors write better proposals.
Why this matters: Without evaluation criteria in your RFP template, website proposal comparisons end up coming down to gut feeling. And gut feeling tends to default to price, which is exactly the wrong factor to optimize for. Define your criteria up front, share them with vendors, and then use them during evaluation.
For a detailed framework on how to score and compare the proposals you receive, see our guide to evaluating website proposals.
Section 11: Submission Requirements
What it is: The logistics of responding.
What to include:
- Submission deadline (date and time, with time zone)
- Format requirements (PDF, email, portal)
- Maximum page count (if any)
- Contact person for questions
- Whether there will be a Q&A period or a pre-proposal call
- How and when you'll communicate your decision
What vendors appreciate: A Q&A period or pre-proposal call. The best RFP processes include an opportunity for vendors to ask clarifying questions. This isn't extra work for you. It's how you get better proposals.
If a vendor has a question about your AMS integration, the answer will improve every response you receive. But the organization has to be prepared to actually answer questions. Responding with "why don't we see what you come up with" is unfair, and you will lose good vendors who don't want to play that game.
What signals inexperience: No contact person listed. RFPs that say "submit to [email protected]" with no named individual specified suggest that no one owns the process internally. Vendors want to know that there's a real person on the other side who will read what they submit.
Section 12: Post-Launch Requirements
What it is: The section that every other RFP template leaves out.
What to include:
- Ongoing hosting requirements (managed hosting vs. self-hosted)
- Maintenance expectations (plugin and core updates, security monitoring)
- Support needs (response time expectations, types of issues covered)
- Training (how many people, what format, how many sessions)
- Performance expectations (uptime, page speed, security standards)
- Whether you want to evaluate post-launch support separately or as part of this RFP
Why You Need This Section
This is the gap I see most often, and it creates the most problems after launch. Organizations write RFPs focused entirely on the build and give zero thought to what happens on day 31. Then they're surprised when their new website starts to degrade within 12 to 18 months because no one is maintaining it.
It's a common scenario for us. We get calls from organizations that say, "We just launched a new website, and we've decided we're not going to use the vendor who built it for hosting and support because we're not happy." That dissatisfaction almost always traces back to a scope and process that were never well-defined, which goes directly back to the RFP.
If the client were truly happy with the outcome, they wouldn't be looking for another vendor before the site is even a year old.
One vendor's proposal includes 12 months of support. Another quotes just the build. Without post-launch requirements in the RFP, you can't compare these proposals on equal terms.
Maintainability as a Differentiator
Our primary concern with any website project is the maintainability of the final product. What we care about is the technical direction the responding agency plans to take. Are they going to use a commercial theme and a bunch of plugins? Or are they going to build a custom theme with a limited number of carefully chosen tools?
When they look at technical requirements, do they answer every problem with "install another plugin," or do they think about the system as a whole and build something efficient?
I've seen some beautiful websites that are absolute spaghetti code underneath. A post-launch requirements section in your RFP forces vendors to think beyond the launch party and tell you how the site will be maintained for years to come.
Section 13: Appendices
What it is: Supporting documentation that provides depth without bloating the core RFP.
Common appendices:
- Current sitemap or content inventory
- Brand guidelines or style guide
- Analytics screenshots or summary reports
- Technical architecture diagrams
- Integration documentation or API specs
- Regulatory or compliance requirements
- Sample content or content style examples
- Organization chart (if relevant to decision-making)
The appendix strategy: Keep your core document focused on goals, scope, and process, and limit it to 8 to 15 pages. Move supporting detail into appendices that vendors can reference as needed. This respects vendors' time while giving technical team members the depth they need during proposal development.
What Vendors Read Closely vs. What They Skim
Most website RFP template guides won't tell you this, because most are written by people who have never responded to an RFP from the vendor side. Here's what it looks like from the other side of the table.
We read carefully:
- Budget range (first thing most of us look for)
- Timeline and key dates
- Project goals and success metrics
- Technical requirements and integrations
- Evaluation criteria and selection process
- Content responsibility and migration scope
We skim or skip:
- Lengthy organizational history beyond the first paragraph
- Mission statements and values (unless we specialize in the sector)
- Boilerplate legal language (that goes to our contracts team, not the proposal team)
- Detailed page-by-page content specifications (these will change during discovery)
- Generic accessibility language copied from regulations (we already know the standards)
This doesn't mean those sections are unimportant. It means that if you spend three pages on your founding story and one paragraph on your budget, you've inverted your priorities. Front-load the information that helps vendors decide whether and how to respond. Save the supporting context for where it adds genuine value.
Customizing Your Web Design RFP Template
A web design RFP template is only as good as the customization you apply to it. If you're copying another organization's RFP verbatim, vendors will notice. I've seen the same boilerplate language in RFPs from organizations of completely different sizes and sectors. When Section 3 references "our 50,000 members," but the organization is a 10-person nonprofit, it's obvious the template wasn't adapted to fit the organization.
For Nonprofits
Add sections covering:
- Donor and fundraising integration requirements (payment processing, CRM sync, recurring giving)
- Grant or board approval processes and how they affect the timeline
- Accessibility as a mission alignment issue, not just a compliance checkbox
- Volunteer management or event registration needs
A common pattern in nonprofit RFPs is wish lists that exceed the stated budget by two to three times. If your list is $150,000 but your budget is $50,000, prioritize your requirements into three tiers: must-have, should-have, and nice-to-have. This is far more useful to vendors than a flat list where everything appears equally important.
For Associations and Membership Organizations
Add sections covering:
- Member portal and authentication requirements (SSO, AMS integration)
- Event management and registration integration
- Chapter or affiliate structure and multi-site considerations
- Member directory and profile management
- Governance and approval workflows (associations often have committee-driven decision-making that directly affects project timelines)
Association websites are consistently more complex than they appear. The member-facing functionality, integration requirements, and multi-stakeholder approval processes add significant scope. Include an integrations appendix listing every system that needs to connect to the website.
For Redesigns vs. New Builds
A lot of organizations use the word "redesign," hoping it signals a smaller, cheaper project. It usually doesn't. What organizations miss is the question itself: what is a redesign versus what is a rebuild?
There are really two kinds of projects. Those who want a new visual design, and those who want new capabilities, integrations, or administrative tools. The RFP needs to be clear about which one this is. A new visual design on an outdated platform rarely solves the underlying problems.
It's our job as consultants to educate clients on whether this is a redesign or a rebuild, and the distinction doesn't necessarily translate into cost savings either way.
For more on how to approach a redesign project specifically, see our guide to writing a website redesign RFP.
Common Mistakes That Make Vendors Pass
Beyond the structural template, there are patterns in how organizations write RFPs that actively discourage qualified vendors from responding. I've seen every one of these repeatedly.
Over-specification. When an RFP prescribes exact solutions, specifying page counts, layouts, specific plugins, and design elements, it limits the ability of vendors to think critically about the problem. Instead of bringing new ideas, vendors are incentivized to simply meet the stated requirements as efficiently as possible. If your RFP specifies the number of pages, color scheme, section headings, and font choices, you're prescribing the solution before understanding the problem.
Under-specification. The opposite problem. An RFP so vague that vendors can't meaningfully differentiate their proposals. Goals stated as "a modern, user-friendly website" with no metrics, no budget range, and scope described in a single paragraph. The result is proposals ranging from $15,000 to $250,000 with no basis for comparison.
AI-inflated RFPs. A growing problem is organizations using AI tools to expand their RFPs, inheriting complexity wholesale. Requirements multiply, scope inflates, and priorities become harder to see. The result is an RFP that reads as thorough but is actually unfocused. If you use AI to help draft your RFP, use it to organize your thinking, not to generate requirements you haven't actually validated with your team.
Mass distribution. Sending the same RFP template to dozens of website vendors signals that you haven't done your homework on vendor selection. Personally invite four to six agencies you've actually vetted. Your response rate and response quality will be dramatically better.
No mention of content. As covered above, content is the number one cause of website project delays. An RFP that details every technical feature but says nothing about who writes, reviews, and migrates content is setting everyone up for timeline overruns.
For a full list of warning signs to watch for when evaluating the proposals you receive in response, see our guide to red flags in website vendor proposals.
Choosing the Right Vendor From the Responses
Once your RFP goes out and proposals come back, the evaluation process matters as much as the RFP itself. A few principles from having been on both sides of this.
Look Beyond the Portfolio
Most clients evaluate design portfolios because that's what you can see with your eyes. But I visit those portfolio sites and look at what's underneath. Are they building custom themes or using bloated commercial ones? Is the code clean or generated by a page builder? I'm evaluating whether the resulting product will last years and be easily maintainable.
Both types of vendors, real developers and point-and-click operators, claim to be "developers." This is a technical project, and you need technically savvy people working for you.
Ask whether their developers write their own code and understand the server stack. Ask whether they can build a fully custom design or will fit your site into a pre-built theme. Ask whether they build their own plugins or are limited to what's available open source or commercially. These questions tell you a lot. A vendor who provides real custom development services will meet each challenge of your project with creativity and freedom that a point-and-click developer simply can't offer.
Check for Scope-to-Budget Alignment
A cheap proposal is one designed to win the project: give a low number without defining what you're going to build, win the client, then deal with the gap later. If it's too good to be true, it probably is.
You probably don't want your lowest bidder, and you probably don't want your highest bidder either. We saw one recently for a nonprofit in Washington, DC, where a vendor bid $150,000 for a website I would have built for tens of thousands of dollars. There's no regulatory body in our industry, no standard pattern for what people pay for websites. Pricing can be all over the place, and having someone who understands the technical implementation look at the numbers can protect you from obvious price gouging on both ends.
Ask for Hours or Scope-to-Price Mapping
As a non-technical person, look to see whether the vendor has allocated hours to the budget or scope to the price. If neither, ask for those details. Make sure the scope is well-defined or that hours are provided, so you have a way to measure how they arrived at their number.
For a full framework on evaluating proposals, including the questions that reveal real technical competence, see our guides on how to choose a web developer.
The One Thing That Predicts Project Success
After 25 years, I can tell you that a defined scope, understood and agreed to by both sides, is the single best predictor of a successful website project.
If we can start with a list of the things you want me to build, I can check them off, and at the end of the project, I can show you that I've built everything on this list. Then we're both going to be really happy. At that point, if you add something, we both understand it's a new item, and it may affect the budget and timeline. That's completely understandable by both parties.
Without that defined scope, the first time your vendor pushes back, you start to be unhappy. You'll think they're nickel-and-diming you. By the time you've accumulated a few of those moments, it's very hard to end the project on a positive note.
Your RFP is where that scope starts. Not every detail needs to be in the RFP itself, because discovery will surface things you haven't considered. But the RFP should contain enough specificity that your vendor can respond with a proposal grounded in reality rather than assumptions:
- Bulleted lists of what you want the site to do
- What users should accomplish
- What administrators need to manage
- What systems need to connect
That's the website RFP template that produces the best project. Not the longest, not the most formal, not the most polished. The one that honestly tells vendors what you need and gives them the information to respond accurately.
Frequently Asked Questions
How long should a website RFP be?
Whether you're working from a website proposal template or building your RFP from scratch, aim for 8 to 15 pages for the core document, plus appendices for supporting materials like sitemaps, brand guidelines, and analytics reports. That length gives vendors enough detail to respond accurately without discouraging qualified agencies from reading the whole thing. Anything over 25 pages tends to reduce response rates from the vendors you actually want to hear from.
Should I include our budget in the RFP?
Yes. Sharing a realistic budget range is one of the most effective ways to improve proposal quality. When vendors know your budget, they can tell you exactly what they can deliver for that amount instead of guessing. Withholding budget information often results in proposals that range wildly in price with no meaningful basis for comparison.
How many vendors should I send a website RFP to?
Send your RFP to four to six pre-qualified agencies you have actually vetted and would genuinely consider hiring. Mass-distributing an RFP to dozens of vendors signals that you haven't done your homework on vendor selection, and the best agencies will often decline to respond. A targeted distribution produces higher-quality proposals and a much better response rate.
What is the difference between a website redesign and a website rebuild?
A redesign focuses on updating the visual design and user experience while keeping the underlying platform and functionality largely intact. A rebuild involves replacing the technology, adding new capabilities, or rearchitecting the site from the ground up. The distinction matters because it directly affects scope, timeline, and cost, and your RFP should be clear about which type of project you are pursuing.
How long does the website RFP process take from start to finish?
The full process from drafting the RFP to signing a contract with your selected vendor typically takes 9 to 18 weeks. That includes time for writing the document, a vendor Q&A period, proposal development, evaluation, finalist interviews, and contract negotiation. Organizations routinely underestimate this window and then compress the build timeline to compensate, which leads to shortcuts and worse outcomes.
What is the biggest mistake organizations make in website RFPs?
Whether you're using a website proposal template or writing from scratch, the most common and costly mistake is failing to define the scope clearly enough for vendors to provide accurate pricing and timelines. Vague goals, missing budget information, and undefined content responsibilities force vendors to guess, which produces proposals that are impossible to compare on equal terms. A close second is ignoring post-launch requirements entirely, which sets the project up for problems within the first year after launch.
FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. We've been reading, writing, and responding to website RFPs for over 25 years. If you're preparing for a website project and want guidance on the process, get in touch.