Every guide to writing a web design RFP reads the same way: here are 10 sections to include, here's a template, download our PDF. What none of them tell you is what happens on the other side of that email. What a vendor actually thinks when your website proposal request lands in their inbox. Whether they take it seriously or toss it.

I've been on both sides of the RFP process for over 25 years. I've written them, responded to them, won projects through them, and lost projects I should have won. But my relationship with RFPs differs from that of most people writing about this topic. FatLab isn't primarily a design shop competing for builds. We're a managed hosting and support company. We manage roughly 200 WordPress websites, and we inherit and maintain sites long after the build vendor has cashed their check and moved on.

That means our primary concern with any RFP is the maintainability of the final product. I've seen some beautiful websites that are absolute spaghetti code underneath.

What I want to see in an RFP is whether the organization values maintainability, both administrative and technical, and whether they expect the vendor to keep the technology stack as simple and low-overhead as possible. Most RFPs don't mention this at all. And it shows in the sites that get built.

This guide isn't a template. It's what I wish every organization knew before they started the process.

Why Most Web Design RFPs Fail Before They're Even Sent

Here's an uncomfortable truth: 40% of vendors say the RFPs they receive are repetitive and poorly written, according to Responsive's annual survey. Vendors respond to only about 55% of the RFPs they receive. And according to Loopio, the average win rate for RFP responses is around 45%, which means even for the ones agencies bother to respond to, the process fails more often than it succeeds.

The problem isn't the format. It's that most organizations approach their website RFP as a form to fill out rather than a strategic exercise. They find a template online, swap in their organization's name, and produce something that reads like every other RFP their vendors have already seen this month.

We've all read them. "We are seeking a modern, mobile-responsive website with a clean design and strong SEO." That sentence appears, almost verbatim, in the majority of RFPs I've received over the past two decades. And it tells me absolutely nothing about what the organization actually needs.

Do You Even Need a Formal RFP?

Before you spend weeks drafting an RFP, ask whether you actually need one. For many organizations, especially smaller nonprofits and advocacy groups with budgets under $30,000, a formal RFP process is overkill and can be actively counterproductive.

A formal RFP makes sense when:

  • Your organization has procurement rules that require competitive bids
  • The project is large enough that you need to compare multiple vendors' approaches
  • The project is grant-funded and requires documentation of competitive selection

A formal RFP is often the wrong tool when:

  • Your project is straightforward, and your budget is modest
  • You already have a trusted vendor or a strong referral
  • You need to move quickly and can't afford a months-long selection process before project work even begins

For smaller projects, a more conversational approach often yields better results. Identify two or three vendors through referrals and portfolio review, have real conversations about your needs, and compare their proposals. You'll get more thoughtful responses and build better working relationships than you would by sending a formal document into the void.

The rest of this guide is for organizations that do need a structured RFP process, whether by requirement or by choice.

Web developer at their desk reviewing an email inbox while deciding which RFP submissions to respond to

What Vendors Really Think When Your RFP Arrives

I'm going to be honest about something the other RFP guides won't tell you: most quality agencies don't like responding to RFPs. The economics don't work. According to Responsive, a thoughtful proposal takes 25 or more hours of senior staff time. At typical agency rates, that's $3,000 to $7,500 in unrecoverable cost. When you're one of 15 recipients, and there's no budget listed, the math doesn't add up.

That's why the best vendors are selective. And that means the quality of your web design RFP directly determines the quality of vendors who respond to it. A vague, generic RFP doesn't just waste your time. It actively filters out your best options and attracts vendors who respond to everything because they need the work.

The real conversations don't happen until the organization picks its first-round winners. Vendors fill responses with best practices, but if they miss the one thing the marketing director cares about, they're out. More transparency in the RFP means better-targeted proposals for everyone.

What I Look at First in a Website Proposal Request

When an RFP hits my inbox, I make a quick decision about whether to invest the time. Here's what drives that decision:

Is there a budget? This is the single biggest factor. If there's no budget, I probably won't respond. I've written about this extensively because I feel strongly about it. When you don't provide a budget, you're forcing vendors to take shots in the dark. If you tell me what you can spend, I'll tell you what I can do for that. You'd be surprised: if the project is good, or I personally like the client, I might be willing to do a lot more for less. But I don't know any of that yet.

Does the scope make sense? When an RFP says they're a nonprofit that doesn't have much money but then describes needing a website that does everything, that's a red flag. It's like walking into a McDonald's and asking for a fine steak dinner. You might leave full, but you won't be happy.

Is this actually competitive, or is it wired? I've been burned more times than I can count responding to RFPs that were already decided. The organization had its vendor, its board required competitive bids, and I was just making up the numbers. Research confirms this instinct: according to Loopio, incumbent vendors win at 60 to 90 percent rates. When the deck is that stacked, non-incumbent agencies can usually detect it and may decline to invest proposal effort. I've been on the winning side of questionable RFPs, too, and it still doesn't feel right. If I even have a gut feeling that an RFP is rigged for another vendor, I'm not going to bother responding to it.

Are there complaints about previous vendors? Sometimes it's valuable to learn that the organization had a vendor they weren't happy with for legitimate reasons. But if the RFP dwells on past vendors' failures, it raises a flag. Did the vendor fail the client, or did the client fail the vendor? That's a fair question, and it definitely factors into whether I respond.

Overhead view of a desk workspace with a detailed checklist document, sticky notes, and laptop showing careful project scope planning

Scope: The Single Most Important Thing in Your RFP

I always tell clients: if we can start with a list of 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. Because at that point, if you add something new, we both understand it's a new item, and it may affect the budget and timeline. That's completely understandable by both parties.

Without a defined scope in your RFP for website development, the first time your vendor pushes back on something, you're going to feel unhappy. You'll think they're nickel-and-diming you. You'll think they're hard to work with. And that's okay if it happens once or twice, but by the time you've accumulated a few of those moments, it's very hard to end the project on a positive note.

What is the most common scenario when a client is unhappy with their end product? It's often not the quality of what the developer or designer created. It's that they didn't get what they wanted because they didn't know what they wanted. That's why a defined scope matters more than anything else in the RFP.

Vague Scope vs. Specific Scope

The difference between a good scope and a bad one is concrete. Here's what I mean:

Vague: "We are a membership organization, and we want our members to sign in and access member-only material."

Specific: "We are a membership organization with three levels of members. We'd like members to log in and access directories, PDFs, and gated content based on membership level. Members should be able to pay their dues, track payments, and download previous year invoices."

You'd be surprised how many clients look at you like, "Why would you build a member area that doesn't allow donations?" Well, we do. Not all membership organizations are dues-based. If you don't tell us, we don't know. And that's the kind of assumption that derails projects.

Bullet Points Beat Paragraphs

If it doesn't have a bullet, it's out of scope. There's always going to be a slight gray area, but the stronger this list is, the more bullet points you have, the better the project will go, and the happier everyone will feel at the end.

Bulleted lists are better than general descriptions. This gives your vendor a real starting point. It's okay if the list isn't completely organized. I consider it part of my job to consult and organize those things for you. But I need the raw material to work with.

Include Your Budget. Seriously.

I've never understood why this is controversial. There are two kinds of organizations: those that have a budget and know what they want to spend, and those that genuinely don't know what things cost. Both are fine. But you need to be upfront about which one you are.

If you have a defined budget, share it. We're all playing on the same field. I can decide what I can do for you at that price point. Your proposals will be comparable because everyone is working from the same constraints.

If you don't know what's reasonable, say so. Declare that you're looking for guidance on what things cost. Maybe share a range if you have one. That's fair. What's not fair is saying "let's see what you come up with" and then rejecting proposals because they came in higher than a number you never shared.

When you don't provide a budget, you're essentially choosing the vendor based on whether they happened to hit your number. And that may not be your best vendor.

I personally skip a lot of RFPs where the organization is clearly just shopping around without a clear budget. A lot of really good vendors do the same. During Q&A sessions, some organizations say, "Well, why don't we see what you come up with?" That is, in my mind, unfair business. You're going to lose a lot of really good vendors, because we're just not going to play that game.

What Websites Actually Cost

Since so many organizations don't know what to budget, here are realistic ranges based on what we see in the market. The average cost of a website redesign is approximately $42,500 according to industry surveys, and most projects fall in the $32,000 to $48,000 range.

Mid-range website with custom design, responsive layouts, standard integrations, and content migration typically runs $10,000 to $50,000. This is where most small-to-medium businesses and small nonprofit projects land.

Professional nonprofit or association website with custom design, UX research, membership or donor management integration, event management, accessibility compliance, and content strategy typically runs $30,000 to $60,000. This is where the majority of the nonprofit website projects we see land.

Complex websites with custom application development, multiple system integrations, multilingual support, and advanced functionality start at $60,000 and can reach $150,000 or more.

And these are just the build costs. Ongoing costs that most RFPs completely miss include:

  • Hosting ($50 to $500 per month)
  • Maintenance and support ($300 to $2,000 per month, depending on scope)
  • Content updates
  • Security monitoring
  • Annual plugin and license renewals ($500 to $2,000 per year)

Your RFP should indicate whether the budget includes ongoing maintenance or is build-only, and ask vendors to quote post-launch support separately so you can compare the total cost of ownership, not just the initial build price.

You don't need to share an exact number. A range, like "$40,000 to $65,000 for design and development, $500 to $1,000 per month for ongoing support," gives agencies enough to propose meaningfully.

"Redesign" vs. Rebuild: Why the Distinction Matters

Organizations love the word "redesign" because it sounds smaller and cheaper than "rebuild." But in most cases, what they're describing is a rebuild.

We see two kinds of projects. Some organizations are perfectly happy with how their website functions from an administrative standpoint, but they want a cooler, nicer-looking design. And some organizations want new administrative tools, new integrations, and new capabilities. The RFP needs to be clear about which one it is.

Here's the reality: there's really no point in putting a new coat of paint on an old system. With WordPress, depending on how the original theme was set up, you can sometimes replace a theme without rebuilding. But if the site was built with a page builder, it may not be practical to treat it as a simple redesign.

Even when the design stays the same, and you're just adding new functionality, you're still doing a rebuild. Treating the old site as your design spec can save time on the design process, but the development work is still substantial.

It's our job as consultants to educate clients on whether their project is truly a redesign or a rebuild, and to explain that the distinction doesn't necessarily translate into cost savings either way. Organizations shouldn't use the word "redesign" in hopes of getting a lower bid. A good vendor will call that out, and a bad vendor will just deliver less than you expected.

For a deeper look at how redesign projects differ from new builds, and what your RFP should address for each, see our guide to writing a website redesign RFP.

Stop Writing Website RFPs That All Sound the Same

The biggest thing organizations get wrong after 25 years hasn't changed: their RFPs are cookie-cutter. They're focused on the wrong things. "Must be mobile responsive." "SEO optimized." "Sleek modern design." That's not a scope. That's a wishlist of buzzwords.

A modern website should be mobile responsive. That's a given. But rather than stating that as a requirement, ask your responding agency to analyze your actual mobile usage and determine what that mobile user experience should be. When you look at Google Analytics for many of the nonprofits and associations we work with, less than 20% of their users are on mobile devices. "Mobile-first design" might be the wrong priority entirely.

The same thing happens with SEO. "Built for SEO" doesn't mean anything actionable. What you should be asking for is a discovery process. Are you competing for high-traffic keywords, or is this a small niche that just needs best practices? Do you already have an SEO firm? These questions lead to real answers. "SEO optimized" doesn't.

Accessibility Requirements in 2026

Here's one that most RFPs skip entirely: accessibility. As of April 2026, the DOJ's ADA Title II rule requires WCAG 2.1 Level AA compliance for all web content from state and local governments serving populations of 50,000 or more. The April 2027 deadline applies to smaller entities.

Even if this specific rule doesn't technically cover your organization, the trend is clear. ADA lawsuits against nonprofits and associations continue to rise, many grant-making organizations now require accessibility compliance, and WCAG 2.1 AA should be the baseline requirement in any 2026 website RFP. Your RFP should require vendors to explain their accessibility approach, their testing methodology, and how they'll validate compliance before launch.

The RFPs that produce the best projects are the ones that describe what the organization wants users to be able to do. Not "sleek modern design" but "our members need to log in, access continuing education materials, pay dues, and download certificates." That gives a vendor something real to work with.

Templates Are Fine (If You Use Them Right)

There's absolutely nothing wrong with using an RFP template. In fact, I encourage it. If you're getting a template from a place like FatLab, what we're providing is the outline we'd like to see. If you structure your RFP the way we'd like, we can answer it more accurately. A more accurate answer gives you better timelines, better budget estimates, and a tighter scope.

The key is using the template as a thinking tool, not a checklist to rush through. Whether or not you follow the template exactly, if it guides you toward the right questions and helps you organize the information vendors need, the resulting proposals will be far more accurate.

Pull more than one template. Compare them. Use them to make sure you haven't missed anything. The more precise your RFP, the more precise the responses.

We've put together a website RFP template that reflects what vendors actually need to see, along with real examples of effective vs. ineffective RFP language to help you see the difference specificity makes.

Nonprofit board members seated around an oval table discussing website proposals with laptops, documents, and a presentation screen

Nonprofit RFP Considerations

We work with many nonprofits and associations, and the RFP process plays out differently in that world. Many have bylaws that require competitive bids, particularly for projects funded by government grants, where federal Uniform Guidance requires competitive procurement above certain thresholds.

I'll be blunt: I don't like these because the incumbent or another firm is often already identified as the winner. They have every intention of awarding the job to that vendor, but they still have to collect competing bids.

The Wired RFP Problem

What happens next is something I consider unethical, but it happens a lot. The organization collects all the bids, gathers up the good ideas, any scope suggestions, and the pricing, and 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.

I've been on the receiving end of these. You submit, and almost as fast as you hit send, you get a note thanking you for your time, but they've decided to go a different direction. You can just feel it.

I've also seen the scenario where there's an incumbent and the organization has bylaws that require them to review contracts every so many years. The incumbent is being pressured to review their fees while being threatened with replacement. That scenario is just unfair to everyone involved.

If your organization has procurement rules that require competitive bids, run an honest process. Be transparent about whether you have an incumbent relationship. Genuinely evaluate alternatives. Your vendors can tell when it's theater, and the good ones won't participate again.

Stakeholder Complexity

Nonprofit website projects also involve more stakeholders than their private-sector equivalents: executive directors, board technology committees, development staff focused on the donor experience, program staff focused on service-delivery content, communications teams focused on brand and messaging, and finance teams focused on grant compliance.

Your RFP should identify who has decision-making authority and who has input-only roles. Without this clarity, the project stalls at every approval point, and board approval alone can add 2 to 4 weeks when meetings occur monthly or quarterly.

Budget Realities for Nonprofits

Your website is a 24/7 window into your organization. Especially for those with membership portals, dues collection, and event management, this is not the place to cut corners. A website that handles thousands of member interactions, processes payments, and delivers content around the clock is remarkably cost-effective compared to the staff it would take to do those things manually. A well-built website will serve you for years.

But if your budget is genuinely below market rate, the only way to attract quality vendors is to be upfront and honest about it. Don't sugarcoat it. Don't promise a great portfolio piece. Don't promise your members will hire us. Don't tell us you're well-connected and can get us more jobs.

In 25 years of business, I have yet to be made or broken by such promises. I value them at zero dollars. It just doesn't happen. Be honest about your constraints and find someone who cares about your cause.

For procurement considerations specific to nonprofits and associations, including grant-funded projects and board involvement, see our nonprofit website RFP guide.

Top-down view of a workspace with multiple printed vendor proposals spread out side by side with colored tabs and a comparison spreadsheet on a laptop

Evaluating Proposals: Where the Real Work Begins

This is where most RFP guides end, and it's where the real work begins. You've sent out your RFP, and now you have three to five proposals sitting in front of you. How do you compare them?

Start with a scoring structure. A weighted scoring matrix keeps the evaluation objective and prevents the loudest voice in the room from dominating the selection. A common weighting:

  • Technical approach: 30%
  • Relevant experience: 25%
  • Cost: 20%
  • Timeline and availability: 15%
  • Team or cultural fit: 10%

Share your evaluation criteria in the RFP itself. This builds trust with vendors and ensures their responses address what matters most to you.

What I Look for in Proposals

I've served as a technical consultant for clients, evaluating proposals from other vendors. In these cases, we handle hosting, maintenance, and security long-term while the client works with another vendor for the build. Here's what I look for:

Technical competence, not just pretty portfolios. Most clients evaluate design portfolios because that's what they can see. But I visit those portfolio sites. Assuming it's WordPress, I look at the markup and figure out which themes they're using. Are they building custom themes or using bloated commercial themes? How many plugins does it look like are installed? What are they using for common features like forms? Is the CSS clean or generated by a page builder? I'm evaluating whether the resulting product will last years and be easily maintainable. If I find a portfolio full of commercial themes and heavy plugin usage, that's a red flag.

Budget-to-scope alignment. We saw one recently for a nonprofit in Washington, DC: a website I would have built for tens of thousands of dollars, and the vendor had bid $150,000. That's a case of someone taking advantage of a client who didn't understand the technical implementation of what they were asking for. There's no regulatory body in this industry, no standard pattern for what people pay for websites. Pricing can be all over the place, so you need someone looking out for obvious price gouging.

Whether the proposal actually defines the project. If a proposal says "we will build you a website for X dollars" without explaining what the website will do, we haven't defined the project. Why would we know how much it costs?

Watch for Cheap Proposals

A cheap proposal designed to win isn't doing you any favors either. These bids quote a low number without clearly defining what you're going to get. The theory is: win the client, then deal with it 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.

As a non-technical person, look for whether the vendor has allocated hours to the budget or allocated scope to the price. If neither, get those things. Make sure the scope is well-defined or that hours are provided, so you can measure how they arrived at their number. And if you really like the lowest bidder, go back and have a conversation. Ask them why their bid came in where it did. You'll probably find that things weren't included and the scope wasn't defined.

Red Flags in Vendor Responses

Watch for these warning signs:

  • Generic, reused language that suggests the agency recycled a proposal without customization
  • Excessive boilerplate about company history instead of addressing your specific needs
  • No case studies from similar organizations
  • No questions asked during the Q&A period, which suggests they didn't read the RFP carefully
  • Pricing significantly below all other responses, which usually means missing scope

For a deeper framework on what to look for in proposals, see our guide to evaluating website proposals when you're not technical. And for specific warning signs, see our breakdown of red flags in website vendor proposals.

Questions That Reveal Real Competence

During the evaluation process, some questions will tell you whether you're talking to a real development team or a point-and-click operation. This matters more than most organizations realize.

Ask whether their developers write their own code. Ask whether they understand the full server stack. Ask whether they build custom themes or use commercial ones. Ask whether they can build custom plugins, or whether you're limited to what's available open source or commercially.

Both types of vendors claim to be "developers." But a vendor who provides real custom WordPress development services can meet any challenge with creativity and freedom. A point-and-click developer, someone who installs a commercial theme, changes some colors, and loads up plugins, simply can't offer that.

The problem is that this distinction isn't visible in a portfolio. The sites might look equally polished. The difference is what happens six months after launch when you need something changed.

This is a technical project. You need technically savvy people working for you. Don't accept "we're developers" at face value. Dig in.

We've put together a complete guide on how to choose a web developer or agency that covers the questions worth asking and the answers to listen for.

What Actually Predicts a Successful Project

After 25 years, I can tell you it comes back to one thing: a defined scope that both sides understand and agree to.

We see the consequences regularly. Organizations call us right after launch, looking for a new hosting and support vendor because the build didn't go well. When we dig in, the root cause almost always traces back to a poorly defined scope, which traces back to the RFP itself. If both sides had started with a clear, agreed-upon list of deliverables, those relationships wouldn't have soured.

But scope is just the foundation. The projects that go best share a few other characteristics:

A single decision-maker. Committee-driven projects, where every design choice needs approval from five people with different priorities, consistently produce mediocre results. Designate someone with authority to make decisions and keep the project moving.

Content readiness. This is the number one reason web projects go over budget and behind schedule. Organizations assume content will be "ready when you need it," but writing, reviewing, and approving website content takes far longer than anyone expects. Industry data shows projects with content-ready clients complete 30 to 40 percent faster. If your RFP says nothing about who creates content and who migrates it, you're setting up a budget overrun.

Post-launch planning from the start. The website launch is the beginning, not the end. If your RFP doesn't address ongoing hosting, maintenance, security updates, and support, you're setting yourself up for problems. 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 meaningfully.

At a minimum, your RFP should address:

  • A warranty period (60 to 90 days of bug fixes is standard)
  • Training requirements
  • Handover documentation (source code, credentials, content management procedures)
  • Ongoing maintenance expectations
  • Performance monitoring

These aren't nice-to-haves. They're what separates a website that keeps getting better after launch from one that starts deteriorating the day it goes live.

Realistic timelines. The RFP process alone, from drafting through vendor selection and contract negotiation, typically takes 9 to 18 weeks before project work even begins. A mid-range nonprofit website project then takes another 12 to 20 weeks to build. Organizations routinely underestimate this, then compress the build timeline to hit an arbitrary launch date. A 50-page website with custom integrations cannot launch in 6 weeks, regardless of how many people want it to.

The Most Important Thing in Your Website RFP

If I could give one recommendation to any organization about to start this process, it would be this: document every function your website needs to perform. What should users be able to accomplish? What do administrators need to manage? What integrations are required? What content types exist?

It doesn't have to be polished. That's what your vendor is for. But give us the raw material, the real picture of what you need. And if you have a budget, share it so we're all working from the same constraints.

The web design RFP that produces the best project isn't the longest, the most formal, or the most template-perfect. It's the one that, honestly, tells vendors what the organization needs and gives them the information they need to respond accurately. Everything else follows from that.

Frequently Asked Questions

How long does the website RFP process take from start to finish?

Plan for 6 to 9 months from start to launch. The RFP process itself, from drafting through vendor selection, typically runs 9 to 18 weeks. The build phase adds another 12 to 20 weeks depending on complexity. Organizations that target 3 months end-to-end almost always end up compressing the build timeline, which leads to cut corners and unhappy outcomes.

How many vendors should I send my website RFP to?

Three to five vendors is the sweet spot. Sending to fewer than three limits your comparison options, while sending to more than five creates an evaluation burden and signals to vendors that you're casting too wide a net. Quality agencies are less likely to invest effort in proposals when they know they're competing against a dozen other firms.

Should I include our budget in the RFP if we're a nonprofit?

Yes. Nonprofits benefit even more from sharing a budget range because it prevents vendors from guessing at your constraints. A realistic range like "$30,000 to $50,000 for design and development" tells vendors you've done your homework and helps them propose something achievable. Withholding the budget doesn't protect you; it just drives away experienced vendors who won't gamble their proposal time on it.

What is the difference between a website redesign and a website rebuild?

A redesign means updating the visual appearance of your site while keeping the underlying platform and functionality intact. A rebuild means replacing the technical foundation, adding new features, or migrating to a different system. Most organizations say "redesign" when they actually need a rebuild, and the distinction matters because the scope, timeline, and cost differ significantly.

What should a website RFP include about post-launch support?

Your RFP should ask vendors to quote post-launch support separately from the build cost. At minimum, address a warranty period of 60 to 90 days for bug fixes, staff training requirements, handover documentation including credentials and source code, ongoing maintenance and security monitoring, and hosting arrangements. Without these requirements, you cannot meaningfully compare proposals on the total cost of ownership.

Can I use a free RFP template I found online?

Free templates are a fine starting point, but they should be treated as a thinking tool rather than a form to fill out. The best approach is to pull two or three templates, compare their sections, and use them to ensure you haven't missed anything important. The value is in the thinking process that the template guides you through, not in following any single template exactly as written.

FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. We've been reading, writing, and responding to website proposal requests for over 25 years. If you're preparing for a website project and want guidance on the RFP process, get in touch.