I've been on both sides of the RFP table. As an agency, we've responded to hundreds of them. As a consultant, I've helped companies write them. And here's the thing most guides won't tell you: the vast majority of RFPs are terrible. They're either so vague that every vendor responds with the same generic pitch, or so prescriptive that you accidentally eliminate the teams who'd actually build you the best thing.

This guide covers the full RFP process in 7 concrete steps, specifically tuned for web development and digital projects in 2026. Whether you're sourcing a headless CMS build, a Next.js migration, or a full platform redesign, these steps will help you run a process that actually surfaces the right partner -- not just the cheapest bid. And if you already know what you need and want to skip ahead, submit your RFP and we'll take it from there.

Table of Contents

What Is an RFP and When Do You Actually Need One?

An RFP -- Request for Proposal -- is a formal document that describes your project requirements and invites vendors to submit proposals explaining how they'd approach the work, what it would cost, and why they're the right fit.

But here's the real question: do you actually need one?

For projects under $50K, a formal RFP process often creates more friction than value. You'll spend weeks writing the document, managing responses, and scoring proposals when you could've had three solid discovery calls and made a decision. RFPs make sense when:

  • The project budget exceeds $75K-$100K
  • Multiple internal stakeholders need to align on vendor choice
  • Procurement or compliance requires a documented selection process
  • You're genuinely unsure which technical approach is right (headless CMS vs. monolithic, Next.js vs. Astro, etc.)
  • You need to compare more than 3-4 vendors fairly

If you're a marketing team that just needs a fast site on a modern stack, skip the RFP and reach out directly. Seriously. The best agencies often skip RFPs entirely because the process favors volume responders over quality builders.

That said, when you do need an RFP, doing it well matters enormously. Let's walk through it.

Step 1: Define the Problem Before the Solution

This is where 80% of RFPs go wrong. Teams jump straight to listing features and tech requirements without clearly articulating why they're doing this project.

Before you write a single word of the RFP document, get your internal stakeholders in a room (or a Zoom, let's be honest) and answer these questions:

Business Context Questions

  • What's broken with the current site/platform?
  • What does success look like 12 months after launch?
  • What are the 3 measurable KPIs this project needs to move?
  • What's the hard budget range? (Yes, you need to know this before you write the RFP.)
  • What's the deadline, and is it real or aspirational?

Technical Discovery Questions

  • What systems does the new solution need to integrate with? (CRM, ERP, PIM, analytics)
  • Are there existing technology constraints or preferences?
  • Who will maintain the site post-launch?
  • What's your team's technical comfort level?

We hit this at a financial services client last year. Their RFP listed 200 requirements but never once explained the business problem. Every agency that responded proposed a different thing because nobody understood what "success" actually meant. That's a recipe for proposals that are technically compliant but strategically useless.

Pro tip: Write a one-page project brief before the full RFP. Share it with 1-2 trusted advisors or vendors for a gut check. You'll catch blind spots early.

Step 2: Write the RFP Document

Now you're ready to write the actual document. Keep it between 8-15 pages. Anything longer and you're either over-specifying or including filler that no one reads.

Here's the structure I recommend:

Essential RFP Sections

1. Company Overview (1 page)
   - Who you are, what you do, your audience
   - Current tech stack and platform

2. Project Background (1-2 pages)
   - Why this project exists
   - What's not working today
   - Business goals and KPIs

3. Scope of Work (2-4 pages)
   - Functional requirements (what it needs to do)
   - Content and design expectations
   - Integration requirements
   - Performance and accessibility standards
   - NOT a 47-page feature matrix

4. Technical Environment (1 page)
   - Existing systems and constraints
   - Hosting preferences or requirements
   - Security and compliance needs

5. Proposal Requirements (1-2 pages)
   - What you want in the response
   - Format and length guidelines
   - Specific questions to answer
   - Case studies or references requested

6. Evaluation Criteria (0.5 page)
   - How you'll score proposals (share this!)
   - Weighting of criteria

7. Timeline and Process (0.5 page)
   - RFP response deadline
   - Q&A period details
   - Selection timeline
   - Expected project start date

8. Budget Range (yes, include this)
   - A realistic range, not a ceiling

The Budget Transparency Debate

I know. Sharing your budget feels like showing your cards in poker. But here's why you should do it anyway.

When you don't share budget, three things happen:

  1. The best vendors can't tell if the project is worth their time
  2. You get wildly different scopes that are impossible to compare
  3. Low-quality vendors bid low to win, then change-order you to death

A 2025 Hinge Research Institute study found that 68% of professional services firms prefer RFPs that include budget ranges. You don't need to give an exact number. A range like "$150K-$250K" tells vendors enough to scope appropriately.

If you're working through your RFP document right now and want expert eyes on it, send us your RFP and we'll give you honest feedback on whether it's set up to attract the right partners.

Step 3: Build Your Vendor Shortlist

Don't blast your RFP to 20 vendors. That's a waste of everyone's time, including yours. You'll drown in proposals and won't give any of them the attention they deserve.

Aim for 4-6 vendors. Here's how to build that list:

Where to Find Qualified Web Development Vendors

Source Pros Cons
Clutch.co / G2 Verified reviews, filtered by tech stack Pay-to-play rankings can skew results
Referrals from peers Pre-vetted, honest feedback Limited to your network
Conference speakers Deep expertise signals May not be available
Portfolio review See actual work quality Time-intensive research
Agency directories (Sanity, Contentful, Shopify partner lists) Platform-specific expertise Biased toward that platform

For headless web development specifically, you want vendors who've actually shipped production sites on your target stack. If you're considering a headless CMS approach, look for agencies with proven headless CMS development experience and specific framework expertise in Next.js or Astro.

Pre-Qualification Criteria

Before sending the RFP, do a quick screen:

  • Have they built something similar in the last 18 months?
  • Is their team size appropriate for your project?
  • Do they have relevant case studies with measurable results?
  • Are they responsive in initial communication? (This tells you a lot.)

Step 4: Distribute and Manage the Q&A Period

Send the RFP to your shortlisted vendors with a clear timeline. I recommend this cadence:

  • Day 0: RFP distributed
  • Day 3-5: Optional vendor briefing call (30 minutes, all vendors together or separate)
  • Day 7: Deadline for written questions
  • Day 10: Compiled Q&A sent to all vendors (anonymized)
  • Day 21-28: Proposals due

The Q&A period is critically important and often botched. Here are the rules:

Q&A Best Practices

  1. Compile all questions and share answers with every vendor. No private side-channels. If one vendor asks a great clarifying question, everyone deserves the answer.

  2. Pay attention to the questions themselves. The quality of a vendor's questions tells you more about their expertise than their proposal will. A vendor who asks about your content migration strategy, your analytics setup, or your deployment workflow is thinking about the real work. A vendor who asks zero questions is either arrogant or not paying attention.

  3. Be honest about what you don't know. If a vendor asks "What's your expected monthly traffic?" and you don't have that number, say so. Vendors can handle ambiguity. They can't handle false precision.

  4. Hold the deadline firm. If a vendor can't hit a proposal deadline, they're signaling something about how they'll handle project deadlines.

Step 5: Evaluate Proposals with a Scoring Matrix

This is where most teams wing it, and it's where bias creeps in. Build a scoring matrix before you read a single proposal.

Here's a weighted scoring model I've used on dozens of evaluations:

Criteria Weight Score (1-5) Weighted Score
Technical approach and architecture 25% -- --
Relevant experience and case studies 20% -- --
Team composition and availability 15% -- --
Project management methodology 10% -- --
Timeline and milestones 10% -- --
Pricing and value 15% -- --
Cultural fit and communication style 5% -- --
Total 100% -- --

How to Actually Score Proposals

Assemble a review panel of 3-5 people. Include at least one technical person, one business stakeholder, and the day-to-day project owner. Have everyone score independently before discussing.

Look for these green flags:

  • The vendor pushed back on something in your RFP (this means they're thinking critically)
  • They proposed a phased approach instead of promising everything at once
  • They included honest risk assessments
  • Their case studies include metrics, not just screenshots
  • They explained why they chose specific technologies, not just what they'd use

And these red flags:

  • Copy-pasted boilerplate that doesn't reference your specific project
  • No questions during the Q&A period
  • Price significantly below every other proposal (you'll pay for it later in change orders)
  • Vague timelines with no milestone detail
  • "We can do everything" with no prioritization

Step 6: Conduct Finalist Presentations and Technical Reviews

Narrow to 2-3 finalists. Invite them for presentations, but don't just let them run a slide deck at you. Structure the session so you actually learn something.

0-15 min:  Vendor presents their approach (keep it short)
15-45 min: Technical deep-dive with your dev team
45-60 min: Scenario-based questions (see below)
60-75 min: Team introductions (meet who'll actually do the work)
75-90 min: Open Q&A

Scenario-Based Questions That Reveal Real Capability

Don't just ask "tell us about your process." Give them situations:

  • "Our CEO sees the staging site and wants to completely redesign the homepage two weeks before launch. How do you handle that?"
  • "We discover mid-project that the legacy CMS API doesn't expose the data we assumed it would. What's your approach?"
  • "Post-launch, our traffic spikes 10x due to a viral moment. Walk us through how your architecture handles that."
  • "A critical team member on your side leaves the project. What's your continuity plan?"

These questions reveal how a team actually operates under pressure. Anyone can describe an ideal process. You want to know how they handle the messy reality.

Reference Checks

Don't skip this. Ask each finalist for 2-3 client references from projects completed in the last 12 months. When you call, ask:

  • Did the project come in on budget? If not, why?
  • How did they handle disagreements or scope changes?
  • Would you hire them again?
  • What's the one thing they could improve?

That last question is the most revealing. If a reference can't name a single thing, they're not being honest with you.

Step 7: Negotiate, Select, and Onboard

You've picked your vendor. Now close the deal without destroying the relationship before it starts.

Contract Negotiation Tips

  • Don't negotiate purely on price. If you need to reduce cost, reduce scope. Squeezing margins leads to corner-cutting.
  • Define change order processes upfront. How are additional requests priced? What's the approval threshold?
  • Clarify IP ownership. You should own the final product. The vendor typically retains rights to their proprietary tools and frameworks.
  • Set payment milestones tied to deliverables, not just calendar dates. Something like 20% at kickoff, 30% at design approval, 30% at development completion, 20% at launch.
  • Include performance benchmarks in the contract. Core Web Vitals targets, uptime SLAs, and accessibility standards (WCAG 2.2 AA minimum in 2026).

Onboarding Your New Vendor

The first two weeks set the tone for the entire project. Have these ready:

  • Access to all systems and accounts they'll need
  • A designated internal point of contact with actual decision-making authority
  • Brand guidelines, content assets, and design files
  • A kickoff meeting agenda that covers goals, communication cadence, and escalation paths

Don't hand over a 200-page requirements document and disappear. The best projects are partnerships, and that starts on day one.

RFP Timeline Template for Web Development Projects

Here's a realistic timeline for a mid-to-large web development RFP process:

Phase Duration Cumulative
Internal requirements gathering 2-3 weeks Week 3
RFP document writing 1-2 weeks Week 5
Vendor shortlisting 1 week Week 6
RFP distribution + Q&A 1 week Week 7
Vendor response period 3 weeks Week 10
Proposal evaluation 1-2 weeks Week 12
Finalist presentations 1 week Week 13
Reference checks + decision 1 week Week 14
Contract negotiation 1-2 weeks Week 16
Total RFP Process 14-16 weeks --

Yes, that's 3-4 months before the project even starts. This is why I said earlier: if your project is small enough, skip the formal RFP. For projects where the investment justifies it, this timeline is realistic and rushing it leads to bad outcomes.

Common RFP Mistakes That Cost You the Best Vendors

After years of responding to RFPs, here are the mistakes I see most often from the vendor side:

1. Not sharing the budget. I've already beaten this drum, but it bears repeating. No budget range = a guessing game for everyone.

2. Requiring spec-work. Asking vendors to create mockups, wireframes, or technical prototypes as part of their RFP response is asking for free work. Good agencies will decline. You'll end up with vendors who are desperate, not capable.

3. Over-specifying the technology. Unless you have a genuine technical constraint, don't dictate the stack. Tell vendors what the solution needs to do and let them recommend how to build it. You might discover that Astro is a better fit than Next.js for your content-heavy site, but you'll never learn that if the RFP mandates React.

4. Unrealistic timelines. Telling vendors the RFP is due in 7 days signals that you either don't value their time or you've already picked someone and this is a checkbox exercise. Three weeks is the minimum for a thoughtful response.

5. Committee paralysis. Having 12 people evaluate proposals means no one takes ownership of the decision. Keep the evaluation panel small and give one person final authority.

6. Ignoring cultural fit. The lowest bidder with the most impressive portfolio can still be a nightmare to work with. Pay attention to communication style, responsiveness, and how they handle disagreements during the evaluation process.

FAQ

How long should an RFP document be for a web development project?

Keep it between 8-15 pages. Anything shorter and you're probably not giving vendors enough context to write a meaningful proposal. Anything longer and you're either over-specifying the solution or including information that belongs in a discovery phase, not the RFP. Focus on business goals, functional requirements, and evaluation criteria.

Should I include a budget range in my RFP?

Yes. I know it feels counterintuitive, but sharing a realistic budget range helps vendors scope appropriately and self-select out if they're not a fit. You'll get more comparable proposals and waste less time reviewing wildly different interpretations of your requirements. A range like "$100K-$175K" is specific enough to be useful without locking you in.

How many vendors should I send an RFP to?

Four to six is the sweet spot. Fewer than three and you don't have enough comparison points. More than six and you'll drown in proposals and can't give each one fair evaluation time. Pre-qualify vendors before sending the RFP so every response you receive is worth reading.

What's the typical timeline for an RFP process in 2026?

Expect 14-16 weeks from the start of internal requirements gathering through contract signature. The vendor response period alone should be 3 weeks minimum. Rushing the process almost always leads to picking the wrong vendor or missing critical requirements that surface mid-project.

Can I use an RFI before an RFP?

Absolutely, and it's a smart move for complex projects. An RFI (Request for Information) is a lighter document that helps you understand the market before committing to a full RFP. Use it when you're genuinely unsure about technology choices -- like whether to go with a headless CMS architecture or a traditional monolithic platform. The RFI responses will inform your RFP requirements. Check out our headless CMS development capabilities for context on what to look for.

What evaluation criteria matter most for web development RFPs?

Technical approach and relevant experience should carry the most weight -- around 45% combined. Pricing matters, but it shouldn't be the primary driver. I've seen too many projects go sideways because the team picked the cheapest bid. Weight pricing at 15% and focus more on whether the vendor has actually built what you're asking them to build, with results they can prove.

Should I require vendors to present in person?

In 2026, remote presentations are the standard and there's no quality penalty. Video calls actually have an advantage: you can record them (with permission) for stakeholders who can't attend. If you do want an in-person component, save it for the finalist round with your top 2 vendors, not the initial evaluation.

What should I do if all vendor proposals exceed my budget?

This usually means one of three things: your budget is unrealistic for the scope, your scope is too large for a single phase, or you haven't communicated priorities clearly enough. The best move is to go back to your top 1-2 vendors and ask them to propose a phased approach. Launch with the core functionality in phase one and add features in subsequent phases. Most experienced agencies, including ours, are happy to structure projects this way because it reduces risk for everyone. If you'd rather talk through your options with us directly, get a proposal in 48 hours and we'll help you figure out the right path forward.