What to put in a website redesign RFP before asking for quotes
A website redesign RFP should explain the business situation, audience, problems, constraints, content, technical needs, ownership, budget, and decision process. Define the requirements while leaving room for professional judgment.
Ahmed JamalInsights
Start with context
A website redesign RFP has one main job.
Give serious providers enough context to understand the project and respond to the same problem.
Weak RFPs usually fall into one of two extremes.
One is too vague.
"We need a modern website. Please send price and timeline."
The other prescribes every screen, section, animation, and technical choice before a specialist reviews the business problem.
A stronger RFP sits between those extremes.
Start with business context.
Explain what the company does.
Explain why the redesign is happening now.
Explain what feels weak in the current site.
Explain the audience.
Explain the primary business action.
Explain how success will be judged.
Those details shape every later decision.
A useful RFP describes the problem clearly without designing the answer in advance.
Make scope comparable
Providers need the same baseline if you want useful quote comparisons.
Include the current website URL.
List known pages and page types.
Explain which content stays, changes, or still needs writing.
List required CMS content such as articles, case studies, resources, jobs, team members, or locations.
Explain required forms and integrations.
Mention CRM, booking, analytics, search tools, product data, or external systems already involved.
Explain search requirements.
If the current site earns organic traffic, say so.
Ask how the provider handles URL changes, redirects, metadata, internal links, canonical signals, sitemap updates, and post launch search checks.
Explain ownership.
Who owns the domain?
Who owns the CMS account?
Who owns the design files?
Who owns analytics and Search Console?
What access exists today?
Add a realistic budget range.
A range helps providers recommend a scope which fits the commercial reality.
Add the target launch window.
Then explain whether the date is fixed or flexible.
Explain the decision process.
Who reviews proposals?
Who gives final approval?
What matters most in selection?
Relevant experience?
Direct senior involvement?
Technical depth?
Timeline?
Budget?
Ongoing support?
A provider should know how the work will be judged.
Leave room for judgment
The RFP should define requirements without turning every design choice into a requirement.
Avoid prescribing exact section order unless a real constraint exists.
Avoid choosing a platform before technical needs are understood unless the organization already has a firm platform standard.
Avoid asking every provider to produce unpaid finished concepts.
Ask for thinking instead.
How would they approach discovery?
How would they reduce migration risk?
How do they handle content ownership?
How do they test forms and responsive behavior?
How do they work with stakeholders?
What happens after launch?
Ask for relevant proof.
One close case study gives more information than twenty unrelated screenshots.
A useful RFP creates room for a provider to spot a problem the brief missed.
The business owns the context.
The specialist should help shape the solution.
