I've been on both sides of the RFP process. As a developer, I've received RFPs so vague I could've quoted anywhere from $15K to $150K and both would've been honest. As an agency, I've helped clients rewrite their RFPs after the first round of responses came back with wildly inconsistent proposals. The problem isn't that agencies are trying to rip you off. It's that most RFPs leave too much room for interpretation.

If you're planning a website rebuild in 2026 using modern tools like Next.js, Astro, or a headless CMS, your RFP needs to speak the language of this stack. A generic RFP template from 2019 won't cut it. You need to communicate your technical requirements in a way that lets qualified agencies give you accurate, comparable bids. And when you're ready to move forward, submit your RFP to a team that actually builds with these tools daily.

This guide walks you through every section of a modern web development RFP, with specific guidance for headless architecture projects. I've included a downloadable template structure at the end.

Table of Contents

Why Most Web Development RFPs Fail

Let me be blunt: the typical RFP process is broken because it optimizes for the wrong things. Most templates you'll find online were designed for traditional WordPress or enterprise CMS projects. They focus on feature checklists and page counts, which tells an agency almost nothing about actual project complexity.

Here's what goes wrong:

Too vague on technical direction. Saying "we want a modern, fast website" doesn't help. An agency building on WordPress with a page builder and an agency building on Astro with a headless CMS are solving fundamentally different problems. If you don't specify your technical preferences, you'll get proposals spanning completely different architectures.

No mention of content workflow. You'd be amazed how many RFPs describe the frontend in detail but say nothing about how content will be created, reviewed, and published. For headless CMS projects, the editorial experience is a core deliverable.

Unrealistic timelines bolted onto real complexity. I've seen RFPs asking for a headless commerce platform with personalization, multi-language support, and a design system with a 6-week timeline. Agencies either walk away or pad their quote with enough buffer to absorb the inevitable scope creep.

No budget range. I know, I know. You don't want to "anchor" the pricing. But here's the reality: when you don't include a budget range, you're wasting everyone's time. A $30K project and a $300K project can have the same feature list. The difference is in the depth of execution, testing, accessibility, and ongoing support.

What's Different About RFPs for Headless Architecture

Traditional website RFPs assume a monolithic architecture: one system handles content management, rendering, hosting, and delivery. When you move to a headless setup where your CMS is decoupled from your frontend, the RFP needs to address several additional dimensions.

The Stack Matters More

In a monolithic world, saying "build us a WordPress site" gives an agency 80% of the technical context they need. In the headless world, the stack choices multiply:

Decision Options to Specify Why It Matters
Frontend framework Next.js, Astro, Remix, SvelteKit Affects SSR strategy, build times, hosting costs
Headless CMS Sanity, Contentful, Storyblok, Strapi, Payload Affects content modeling, pricing, editorial UX
Hosting/deployment Vercel, Netlify, Cloudflare Pages, AWS Affects CI/CD, preview deployments, cost
API layer REST, GraphQL, tRPC Affects data fetching patterns and caching
Media handling CMS-native, Cloudinary, imgix Affects image optimization and CDN costs

Your RFP should either specify your preferences or explicitly state that you're open to the agency's recommendation and ask them to justify their choices.

Content Modeling Is a Deliverable

With a traditional CMS, content types are often predefined by the platform or theme. With a headless CMS, content modeling is a design exercise. Your RFP needs to describe your content types, their relationships, and how editors will interact with them. This alone is easily 15-20% of the total project effort on a headless build.

Preview and Publishing Workflows

We hit this at least once a quarter: a client launches a headless site and the editorial team can't preview content before publishing. It tanks adoption. In monolithic CMSes, preview is built in. In headless setups, it requires custom implementation. Your RFP should specify your expectations here. Do you need real-time visual editing? Scheduled publishing? Multi-environment previews?

Section-by-Section RFP Breakdown

Let's walk through each section your RFP should include. I'm going to be specific about what to write and what to skip.

1. Executive Summary

Keep this to one page. Include:

  • Your organization's name and what you do (2-3 sentences)
  • Why you're rebuilding (be honest. "Our site is slow" is more useful than "we want to enhance our digital presence")
  • What success looks like in concrete terms (faster load times, higher conversion, easier content management)
  • Your timeline constraints and any hard deadlines (product launches, events, fiscal year boundaries)

2. Current State Assessment

This is where most RFPs are too thin. Be specific:

## Current State
- Platform: WordPress 6.4 on WP Engine
- Monthly traffic: ~120K sessions (Google Analytics)
- Page count: ~340 pages across 12 content types
- Current Core Web Vitals: LCP 4.2s, CLS 0.18, INP 380ms
- Known issues: Mobile experience is poor, content editors 
  spend ~3 hours per blog post due to formatting issues,
  site search returns irrelevant results
- Integrations: HubSpot (forms + CRM), Stripe (payments), 
  Algolia (search), Google Tag Manager

The more concrete you are here, the more accurate the proposals will be. If you can share Google Analytics screenshots or a Core Web Vitals report, even better.

3. Project Scope and Requirements

Break this into functional requirements and non-functional requirements.

Functional requirements describe what the site needs to do:

  • Page types and templates needed
  • Navigation structure
  • Search functionality
  • Forms and lead capture
  • E-commerce or payment processing
  • User authentication
  • Personalization or A/B testing
  • Multi-language support

Non-functional requirements describe how it needs to perform:

  • Target Core Web Vitals scores (be specific: "LCP under 2.5s on 4G")
  • Accessibility standard (WCAG 2.2 AA is the minimum in 2026)
  • Browser and device support matrix
  • Uptime requirements
  • Security requirements (SOC 2, GDPR, etc.)

If you're writing this RFP right now and want feedback before sending it out, send us your RFP and we'll give you honest input on whether it's ready.

4. Design Requirements

Be clear about what you're providing vs. what you need:

  • Do you have an existing brand/design system?
  • Are you providing Figma mockups or does the agency need to handle design?
  • Do you need a component library/design system as a deliverable?
  • What's your stance on design iteration? How many revision rounds?

5. Content Requirements

This section is critical for headless projects:

  • Who's responsible for content migration? (You, the agency, or shared?)
  • How many content types exist? List them.
  • What's the expected content volume over the next 2 years?
  • Do you need structured content that can be reused across channels?
  • What does your editorial team look like? (2 people? 20?)

Technical Requirements for Next.js and Astro Projects

If you've already decided on your frontend framework or you're leaning toward one, here's what to include in your RFP for the two most popular options in 2026.

Next.js Specific Requirements

Next.js (currently at version 15) is the go-to for dynamic, interactive web applications. If your site needs authentication, real-time data, or heavy interactivity, you're probably looking at Next.js.

Include these in your RFP:

## Technical Requirements: Next.js
- Server Components vs. Client Components strategy
- Rendering approach: SSG, SSR, ISR, or hybrid (specify per page type)
- App Router implementation (not Pages Router)
- React Server Components for data fetching
- Middleware requirements (geo-routing, A/B testing, auth)
- Image optimization approach (next/image + external service)
- Deployment target: Vercel, self-hosted, or other
- Expected build times for full site rebuild
- Incremental adoption strategy if migrating from existing React app

If you want to understand what a modern Next.js build looks like in practice, our Next.js development team has published case studies showing real performance benchmarks.

Astro Specific Requirements

Astro has become the default choice for content-heavy sites that don't need much client-side interactivity. Marketing sites, documentation, blogs, portfolio sites. That's its sweet spot. Astro 5, released in late 2024, introduced Content Layer and Server Islands, which make it even more capable.

## Technical Requirements: Astro
- Content Collections configuration and schema
- Island architecture strategy (which components need hydration?)
- Integration requirements (React, Svelte, Vue islands?)
- View Transitions implementation
- Content Layer API usage with headless CMS
- Static vs. hybrid rendering mode
- Deployment target: Cloudflare Pages, Netlify, Vercel, or other
- Build time targets for full site generation

Astro projects tend to have simpler infrastructure but require thoughtful decisions about where to add interactivity. If you're interested in this approach, our Astro development practice has been building content sites with Astro since v2.

Framework Comparison for Your RFP

Factor Next.js Astro
Best for Dynamic apps, dashboards, e-commerce Content sites, marketing, docs
JS shipped to client More (depends on architecture) Minimal (islands only)
Build times (500 pages) 45-90s (ISR reduces this) 20-45s
Hosting cost (typical) $20-200/mo on Vercel $0-50/mo on Cloudflare/Netlify
Learning curve for editors Moderate Lower
Real-time preview support Excellent (Draft Mode) Good (with middleware)
Ecosystem maturity Very mature Mature, growing fast

Headless CMS Requirements to Include

The CMS decision impacts your project more than most people realize. It's not just about where content lives. It's about your team's daily editing experience for years to come.

Here's what to specify in your RFP:

Content Modeling

## Content Model Requirements
- Blog posts with categories, tags, author profiles, and related posts
- Landing pages with modular, reorderable sections (hero, features, 
  testimonials, CTA blocks)
- Team member profiles linked to case studies and blog posts
- Case studies with structured data (client, industry, results metrics)
- Global settings (navigation, footer, SEO defaults)
- Reusable content blocks (CTAs, banners) shared across pages

Editorial Experience Requirements

Be specific about what your content team needs:

  • Visual/WYSIWYG editing or structured field-based editing?
  • Real-time collaboration (multiple editors working simultaneously)?
  • Approval workflows (draft → review → published)?
  • Scheduled publishing?
  • Content versioning and rollback?
  • Asset management (images, videos, documents)?
  • Role-based access control?

CMS Platform Comparison

CMS Pricing (2026) Best For Notable Strength
Sanity Free tier, then $99-$949/mo Complex content models, developers GROQ queries, real-time collaboration
Contentful Free tier, then $300+/mo Enterprise, multi-team Mature API, marketplace
Storyblok Free tier, then €106+/mo Visual editing, marketing teams Visual editor, component-based
Payload CMS Free (self-hosted), cloud plans available Full control, Next.js native Code-first, self-hostable
Strapi Free (self-hosted), cloud from $29/mo Budget-conscious, open source Flexibility, large community

For deeper guidance on selecting and implementing a headless CMS, check out our headless CMS development services.

Budget, Timeline, and Evaluation Criteria

Setting a Realistic Budget

Here's what headless website projects actually cost in 2026:

Project Type Typical Budget Range Timeline
Marketing site (10-30 pages) $25K - $75K 6-12 weeks
Content-heavy site (100+ pages, blog, resources) $50K - $150K 10-18 weeks
E-commerce (headless, <1000 SKUs) $75K - $250K 12-24 weeks
Enterprise platform (multi-site, personalization) $150K - $500K+ 16-32 weeks

Include a budget range in your RFP. Seriously. Saying "our budget is $60K-$90K" immediately filters out agencies that would've quoted $200K and helps realistic agencies allocate the right team.

If you want a quick reference for what different engagement levels cost, we keep our pricing page transparent.

Timeline Guidance

Include these timeline details:

  • RFP response deadline
  • Decision date
  • Preferred kickoff date
  • Any hard launch deadlines and why
  • Your availability for feedback and approvals

Be honest about your team's bandwidth. If your stakeholders can only review designs once every two weeks, say so. That affects the timeline more than most technical decisions.

Evaluation Criteria

Tell agencies how you'll evaluate proposals. Here's a framework:

## Evaluation Criteria
1. Technical approach and architecture (30%)
2. Relevant portfolio/case studies (25%)
3. Team composition and availability (15%)
4. Timeline and project management approach (15%)
5. Cost (15%)

Notice cost isn't the top criterion. If you're buying based purely on price, you'll get what you pay for.

Common RFP Mistakes That Cost You Money

Listing every feature ever. I've seen 40-page RFPs that include requirements like "site should load fast" and "design should be modern." Focus on the specifics. If it's not measurable or unique to your project, leave it out.

Not sharing your current analytics. Agencies can't propose a realistic migration strategy without understanding your current traffic patterns, top pages, and user flows. Share your Google Analytics data under NDA if needed.

Requiring a fixed bid on a vague scope. Fixed bids work when scope is crystal clear. If you're still figuring out your IA or content model, ask for a phased approach: fixed bid for discovery, then a refined estimate for build.

Ignoring post-launch. Your RFP should specify what happens after launch. Do you need ongoing support? Content training? Performance monitoring? A retainer for iterative improvements? These costs are real and should be part of the proposal.

Sending to too many agencies. Sending your RFP to 15 agencies guarantees that the best ones won't respond. They know the odds are stacked against them and it's not worth the effort. Send to 3-5 qualified agencies max.

RFP Template Structure

Here's a copy-paste-ready outline for your RFP:

# Website Development RFP: [Your Company Name]
## Issued: [Date]
## Response Deadline: [Date]

---

## 1. Executive Summary
- About [Company]
- Project goals (3-5 bullets)
- Success metrics

## 2. Current State
- Current platform and hosting
- Traffic and performance data
- Known pain points
- Current integrations

## 3. Project Scope
### 3.1 Functional Requirements
- [List page types, features, integrations]
### 3.2 Non-Functional Requirements  
- Performance targets (Core Web Vitals)
- Accessibility (WCAG 2.2 AA)
- Security and compliance
- Browser/device support

## 4. Technical Preferences
- Frontend: [Next.js / Astro / Open to recommendation]
- CMS: [Sanity / Contentful / Open to recommendation]
- Hosting: [Vercel / Cloudflare / Open to recommendation]
- Must-have integrations: [List]

## 5. Design Requirements
- Existing brand assets: [Yes/No, link to brand guide]
- Design deliverables expected: [Figma, design system, etc.]
- Revision process and rounds

## 6. Content Requirements
- Content types: [List with descriptions]
- Content migration: [Who handles it?]
- Editorial workflow needs
- Multi-language: [Yes/No, which languages?]

## 7. Budget and Timeline
- Budget range: $[X] - $[Y]
- Target launch date: [Date]
- Key milestones or hard deadlines

## 8. Post-Launch Requirements
- Training needs
- Ongoing support expectations
- Hosting management

## 9. Evaluation Criteria
- [List with weights]

## 10. Submission Requirements
- Format and length expectations
- Required sections in proposal
- Contact for questions
- Deadline and submission method

## 11. Appendices
- Current site analytics summary
- Content inventory (if available)
- Technical architecture diagram (if available)
- Brand guidelines (if available)

Feel free to adapt this to your needs. The key is being specific where it counts and honest about what you don't know yet.

If you're ready to skip the RFP process and talk directly with developers who build with these tools every day, reach out to us. We're happy to help you scope the project before you even write the RFP.

FAQ

How long should a website development RFP be?

Aim for 8-15 pages. Anything shorter probably lacks the detail agencies need. Anything longer and you're likely including unnecessary filler. The template above runs about 10 pages when filled out properly. Focus on specifics: measurable requirements, concrete technical preferences, and real data about your current site.

Should I specify Next.js or Astro in my RFP, or leave it open?

If you have a strong preference or existing team expertise, specify it. If you're genuinely open, say so, but ask agencies to justify their recommendation. The worst approach is leaving it vague and then being disappointed when half the proposals are on a framework you didn't want. Setting a preference, even a soft one like "we're leaning toward Astro for performance reasons," gives agencies useful signal.

Do I need to include a budget range in my RFP?

Yes. Absolutely. I know it feels counterintuitive, but including a budget range actually gets you better proposals. Without a range, agencies either lowball to win or propose their dream architecture that's 3x your budget. A range like "$50K-$80K" tells agencies exactly what level of execution you're expecting. The best agencies won't quote the minimum. They'll show you what they can deliver within your range.

What's the typical timeline for a headless CMS website project?

For a marketing site with 20-50 pages, expect 8-14 weeks from kickoff to launch. Content-heavy sites with 100+ pages, complex content models, and multiple integrations typically take 14-22 weeks. The biggest timeline variable isn't development. It's stakeholder feedback cycles and content migration. Build in buffer for those.

How many agencies should I send my RFP to?

Three to five is the sweet spot. Fewer than three doesn't give you enough comparison. More than five and you're creating a cattle call that top agencies will ignore. Do your research upfront: review portfolios, check case studies, and verify they've actually built projects with your preferred tech stack before sending the RFP.

What's the difference between a headless CMS and a traditional CMS for RFP purposes?

With a traditional CMS like WordPress, the CMS handles both content management and page rendering. Your RFP can focus mainly on features and design. With a headless CMS, the content system and the frontend are separate applications that communicate via API. Your RFP needs to address both systems independently: the CMS configuration, content modeling, editorial workflows, AND the frontend framework, rendering strategy, hosting, and how they connect. It's essentially two projects in one.

Should I ask for a fixed-price bid or time-and-materials?

It depends on your scope clarity. If your requirements are well-defined and unlikely to change (rare, but it happens), fixed-price gives you budget certainty. If you're still exploring or expect the project to evolve, time-and-materials with a budget cap is more honest. Many agencies in 2026 prefer a hybrid: fixed price for discovery and design, then T&M for development with weekly budget tracking. Ask agencies which model they recommend and why.

What post-launch support should I include in my RFP?

At minimum, specify a warranty period (30-90 days for bug fixes), training for your content team, documentation for the technical setup, and hosting/monitoring expectations. Ideally, also include a monthly retainer for ongoing improvements. Headless sites benefit enormously from iterative performance optimization and content model refinements in the first 6 months after launch. If you've got your requirements mapped out and want to move quickly, get a proposal in 48 hours from our team.