Blog
 » 

Webflow

 » 
How to Write a Website Redesign RFP

How to Write a Website Redesign RFP

How to write an effective website redesign RFP — what to include, how to structure it, and how to evaluate agency responses fairly.

Daniel Moreno

By 

Daniel Moreno

Updated on

Jul 10, 2026

.

Jesus Vargas

Reviewed by 

Jesus Vargas

Founder

Why Trust Our Content

How to Write a Website Redesign RFP

A poorly structured website redesign RFP generates incomparable proposals, attracts wrong-fit vendors, and wastes months of procurement time.

Knowing how to write a website redesign RFP that works is one of the highest-leverage skills a digital marketing or procurement professional can develop.

The good news is that most RFP problems are structural. The sections are either missing, vague, or in the wrong order.

A properly structured RFP takes a week to write well and saves months of confusion, for both the organization issuing it and the vendors responding.

 

Key Takeaways

  • Scope clarity drives proposal quality: Agencies can only price what is defined, vague RFPs generate vague, high-variance proposals that are impossible to compare.
  • Include your budget range: Withholding your budget forces agencies to guess, publishing a realistic range filters misaligned vendors faster and gets more accurate proposals.
  • Technical requirements need their own section: Platform preferences, integrations, performance requirements, and accessibility standards must be specified separately from design needs.
  • A good RFP tells a story: The best RFPs communicate business context, not just deliverable lists, vendors who understand your goals write better proposals.
  • Ask for process, not just portfolio: The best predictor of a successful redesign is the agency's process, not their visual portfolio aesthetics.

 

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

 

What Makes a Website Redesign RFP Work (or Fail)

The quality of proposals you receive is a direct function of the quality of your RFP.

Vague inputs produce vague outputs, and the consequences play out across months of misaligned vendor conversations. Start by establishing define redesign project scope clarity as the foundation of the entire document.

Most RFP failures are preventable. Understanding the failure modes helps you avoid them before the document is distributed.

 

RFPs That Generate Incomparable Proposals

  • Vague scope produces wide price variance: "Redesign our website to be more modern" generates proposals ranging from £5,000 to £500,000, impossible to evaluate on any rational basis.
  • Missing page counts force assumptions: Without specifying page templates, total page count, and any pages excluded from scope, vendors make wildly different assumptions about project size.
  • Undefined deliverables invite interpretation: An RFP that does not specify whether wireframes, a design system, or post-launch support are required will receive proposals where some include them and some do not.

 

RFPs That Attract the Wrong Vendors

  • Distribution without qualification criteria wastes time: Sending an RFP to 20 agencies without pre-qualifying for relevant experience results in evaluating 15 irrelevant proposals.
  • No minimum qualification threshold invites noise: State minimum requirements, years in business, relevant portfolio examples, platform certifications, in the RFP itself to self-select serious respondents.
  • Too broad a distribution signals low seriousness: Vendors who receive RFPs circulated to 30+ agencies invest less in their response, quality agencies prioritize well-targeted opportunities.

 

What a Good RFP Communicates

  • Business context comes before deliverables: The best RFPs explain why the redesign is happening, what problem it must solve, and what success looks like in measurable terms.
  • Goals are specific and outcome-oriented: "Increase qualified demo requests by 25% within six months of launch" is a goal, "improve user experience" is not.
  • Evaluation criteria are published upfront: Vendors who know how they will be scored write proposals that directly address each criterion, producing more useful, comparable responses.

 

Section 1, Organization and Project Background

Writing a strong redesign proposal is only possible when the RFP provides sufficient context. Section 1 is where you give vendors the business understanding they need to respond with genuine insight rather than generic methodology.

This section is where most vendors decide whether your project is worth a serious response, the quality of your project background determines the quality of vendor engagement.

 

About Your Organization

  • Describe your business model and audiences: Include organization size, primary audience segments, geographic reach, and any relevant industry context that shapes the website's purpose.
  • Explain why the redesign is happening now: The business trigger, a rebrand, growth phase, competitive pressure, or performance decline, gives vendors context that shapes their proposed approach.
  • Share current performance data honestly: Organic traffic volume, current conversion rates, and known performance gaps help vendors understand the starting point and calibrate their proposed solution.

 

The Current Website's Situation

  • State the platform and page count: Current CMS, approximate total page count, and any platform constraints or preferences vendors should know about upfront.
  • Describe the specific problems: "Our bounce rate on the homepage is 78%," "our mobile experience scores 32 on PageSpeed", specific problems invite specific solutions.
  • List any non-negotiable technical constraints: Existing system integrations that must be preserved, hosting requirements, security standards, or accessibility obligations that vendors must accommodate.

 

Project Goals and Success Criteria

  • Write goals in measurable terms: "Increase demo request conversion rate by 30%" rather than "improve user experience", specific goals attract vendors who know how to deliver specific outcomes.
  • Separate primary goals from secondary goals: Primary goals define success; secondary goals are improvements that would be beneficial but are not the primary measure of project success.
  • Include the measurement methodology: State how and when you will measure success, this shows vendors that results accountability is built into the project from day one.

 

Section 2, Scope of Work and Deliverables

The scope section is where most RFPs fail, and where the most procurement time is wasted in vendor clarification conversations. Review scope of work in redesign guidance to understand every component a complete scope section must address.

A well-defined scope section is the single most impactful change you can make to an underperforming RFP.

 

Defining the Page Scope

  • List key page templates required: Homepage, service page, case study template, blog article, contact page, name every template type rather than leaving the list open to interpretation.
  • State the approximate total page count: "Approximately 35 pages across 6 template types" gives vendors a meaningful sizing reference for their effort estimates.
  • Explicitly exclude pages if applicable: If the blog archive, legacy resource pages, or any platform sections are out of scope, state this explicitly, do not assume vendors will know.

 

Design Deliverables Required

  • Specify whether wireframes are required: If you expect wireframes as a deliverable before visual design begins, say so, some vendors skip this step unless explicitly required.
  • State the number of design concepts: One full concept, two concepts for comparison, or a single direction developed iteratively, this significantly affects design investment and timeline.
  • Identify required breakpoints: Desktop, tablet, and mobile breakpoints are standard, any additional responsive considerations (large monitor, app wrapper) should be specified.

 

Development and Technical Deliverables

  • State your CMS preference or openness: If you have a platform requirement (WordPress, Webflow, custom), specify it, if you are open to recommendations, state this explicitly and explain why.
  • List integration requirements by category: CRM, marketing automation, analytics, booking, payment, and any custom API connections, with a note on which are mandatory versus preferred.
  • State the accessibility standard required: WCAG 2.1 AA is the standard baseline, if you have a higher or specific requirement, state it clearly so vendors price compliance work accurately.

 

Section 3, Technical and Functional Requirements

Capture redesign requirements properly in a dedicated technical section, separating these requirements from design requirements prevents confusion about what falls under which workstream.

Technical misalignment is the most expensive form of scope dispute, catching it in the RFP stage prevents it from appearing mid-project.

 

Platform and CMS Requirements

  • State hosting requirements clearly: Self-hosted, cloud SaaS, managed WordPress, or platform-specific hosting, each has different performance, security, and cost implications for vendors.
  • Specify domain and SSL requirements: If you have existing domain configurations, multi-domain requirements, or SSL certificate constraints, document these for vendors to factor into their approach.
  • Describe any existing platform constraints: Legacy content management requirements, specific plugin dependencies, or technical debt that vendors must work around or address.

 

Integration Requirements

  • List every required integration by name: HubSpot, Salesforce, Calendly, Stripe, Klaviyo, specific platform names prevent vendors from pricing vague "CRM integration" work.
  • Classify each as must-have or nice-to-have: Vendors can include all must-have integrations in their base proposal and price nice-to-haves as optional add-ons.
  • Describe any custom API requirements: Custom integrations with proprietary systems require significantly more development effort, describe the data flow and expected functionality.

 

Performance, Security, and Accessibility Requirements

  • State a minimum PageSpeed score: A target of 85 or above on Google's Lighthouse performance tool is a reasonable baseline standard for most organizations.
  • Specify your WCAG compliance level: WCAG 2.1 AA is the professional baseline, public sector and healthcare organizations often require specific compliance documentation.
  • Include security and data handling requirements: SSL, form validation, GDPR compliance, data retention policies, and any relevant sector-specific security standards must be specified.

 

Section 4, Vendor Qualifications and Evaluation Criteria

Choose the right redesign agency by publishing your evaluation criteria upfront. Vendors who know how they will be scored invest in addressing each criterion directly, producing more useful, comparable responses.

Transparent evaluation criteria produce better proposals and make your final selection more defensible to internal stakeholders.

 

Qualification Requirements for Submission

  • State minimum years in business: Five or more years in business with relevant portfolio examples is a reasonable baseline filter for most mid-market RFPs.
  • Require relevant portfolio examples: Ask for three examples of similar projects, similar industry, similar scope, similar platform, with brief outcome descriptions.
  • Ask for platform certifications if relevant: Webflow Enterprise Partner, WordPress VIP, or HubSpot CMS certification signals genuine platform depth rather than claimed competence.

 

Information Required in the Proposal

  • Project understanding and approach: Ask vendors to demonstrate that they understand the specific business problem, not just describe their standard redesign methodology.
  • Team composition and roles: Request named individuals with roles and relevant experience, not generic team size or aggregate years of experience.
  • Itemised pricing with timeline: Require line-item pricing by phase and a phased project timeline with key milestones and client input events.

 

Evaluation Criteria and Weighting

  • Strategic approach (30%): Evidence that the vendor understands the business problem and has a relevant, specific proposed solution.
  • Portfolio and relevant experience (25%): Demonstrated experience with similar project scope, platform requirements, and industry context.
  • Team qualifications (20%): Named individuals with credentials and experience directly relevant to the technical and design requirements of the project.
  • Pricing structure (15%): Transparent, itemised pricing with reasonable milestone payment terms aligned to project deliverables and client approvals.
  • References and track record (10%): Quality of client references and evidence of successful delivery on projects of comparable scope.

 

Section 5, Timeline and Selection Process

Selecting a redesign company requires a structured process, and publishing that process in the RFP signals professionalism to the vendors you most want to attract.

High-quality agencies evaluate how organized procurement processes are before deciding how much to invest in their responses.

 

Establishing a Realistic RFP Timeline

  • Allow 10 to 14 days for proposal preparation: Complex redesign proposals require significant effort, a compressed deadline produces lower-quality responses and may deter serious vendors.
  • Publish all milestone dates upfront: RFP distribution, Q&A deadline, proposal submission deadline, shortlist notification, presentations, and award date, set expectations from day one.
  • Build in contingency at each stage: Selection processes reliably take longer than planned, a two-week buffer between proposal submission and final award prevents timeline pressure on quality evaluation.

 

Allowing Time for Vendor Questions

  • Publish a structured Q&A window: Allow vendors 10 to 14 days to submit written questions after receiving the RFP, with answers published to all respondents simultaneously.
  • Anonymise all questions in the published Q&A: Protecting question sources encourages vendors to ask clarifying questions they might otherwise avoid for competitive reasons.
  • Use questions to identify RFP gaps: If multiple vendors ask the same question, the RFP has a gap that should be addressed with an addendum distributed to all respondents.

 

Selecting the Winning Vendor

  • Shortlist to three finalists maximum: A shortlist of five or more becomes difficult to evaluate fairly, three finalists gives each vendor adequate presentation time and evaluation focus.
  • Use 60-minute vendor presentations: Structured presentations with a consistent agenda, problem understanding, proposed approach, team introduction, and Q&A, enable fair comparison.
  • Check two to three client references before awarding: Reference checks on comparable projects reveal delivery quality and client relationship management that no proposal document can demonstrate.

 

Conclusion

A well-written website redesign RFP is an investment that pays for itself in better vendor alignment, more accurate proposals, and a faster path to project award.

The clarity you provide upfront is the clarity you get back in proposals, and the clarity that prevents misunderstandings through the life of the project.

Start with Section 1 this week. Writing the project background and goals forces the internal alignment that makes every subsequent section easier to draft.

Many organizations discover during this exercise that they do not yet have consensus on goals, finding that out before issuing the RFP is significantly better than finding out after awarding the project.

 

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

 

LOW/CODE Agency Responds to Well-Written RFPs With Proposals That Match Your Goals

At LOW/CODE Agency, we respond to structured RFPs with structured proposals.

Every response we produce is built around a genuine understanding of the specific business challenge the RFP describes, not a standard methodology template with your name substituted in.

We are a strategic product team, not a dev shop.

Our proposal process follows a discovery-first approach: we read the RFP carefully, identify the specific business problem, and structure our response around the outcomes you are trying to achieve. Our itemised pricing and transparent delivery methodology make comparison straightforward.

  • Structured Discovery Response: We analyze every RFP for business context and goals before writing a single word of our proposal, your problem informs our entire approach.
  • Itemised Scope Proposals: Every proposal includes a detailed scope of work with explicit in-scope deliverables, out-of-scope exclusions, and a change order policy.
  • Named Project Team: We identify the specific people who will work on your project, project manager, lead designer, lead developer, with relevant experience included.
  • Transparent Phased Pricing: Our pricing is broken down by project phase with milestone payment terms aligned to client approval events throughout the engagement.
  • Platform Expertise: We have deep expertise in Webflow, WordPress, and custom builds, and we recommend the platform that best fits your requirements, not the one we prefer.
  • SEO and Technical Integration: Our proposals include SEO protection, redirect strategy, performance requirements, and accessibility compliance as standard deliverables, not add-ons.
  • Post-Launch Support Terms: We define our post-launch support period, response time commitments, and training coverage in every proposal, so expectations are set before work begins.

Our clients include Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku, and we have delivered 450+ digital products with the transparency and process rigour that every proposal reflects.

Start with a scoping call to see how we would approach your RFP, or explore our website redesign agency services to understand what a LOW/CODE Agency engagement includes from brief to launch.

Last updated on 

July 10, 2026

.

Daniel Moreno

Daniel Moreno

 - 

Web Developer

Daniel is a Web Developer at LOW/CODE Agency who has been building websites in Webflow since 2022. With a background in graphic design, he turns the design team's concepts into fast, responsive sites

Custom Automation Solutions

Save Hours Every Week

We automate your daily operations, save you 100+ hours a month, and position your business to scale effortlessly.

FAQs

**Allowing Time for Vendor Questions**

**Selecting the Winning Vendor**

Watch the full conversation between Jesus Vargas and Kristin Kenzie

Honest talk on no-code myths, AI realities, pricing mistakes, and what 330+ apps taught us.
We’re making this video available to our close network first! Drop your email and see it instantly.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Why customers trust us for no-code development

Expertise
We’ve built 330+ amazing projects with no-code.
Process
Our process-oriented approach ensures a stress-free experience.
Support
With a 30+ strong team, we’ll support your business growth.