Umvix
All posts
Web DevelopmentProcessHiring

How to write a website RFP that works

Most RFPs produce quotes you cannot compare. A short template, plus the five questions that reveal which agencies actually understood your brief.

Umvix Team 3 min read
Share

We read a lot of RFPs. The good ones take an afternoon to write and get proposals you can genuinely compare. The bad ones take weeks, run to forty pages, and still produce five quotes with a 5x spread.

The difference is not length. It is which questions get answered.

What agencies actually need from you

1. The business goal, in one sentence. Not "we need a new website" — why. "Our sales team spends hours answering questions the site should answer." "We rank for nothing." "The site does not work on phones and half our traffic is mobile." Everything else follows from this.

2. What exists today. Current URL, platform, hosting, CMS, analytics access, traffic. Tell us the awkward parts too — the half-finished migration, the plugin nobody can remove. Surprises found in week three cost more than problems disclosed on day one.

3. Page types, not a page list. "Service page, case study, resource, pricing, contact" tells us the design system. "47 pages" tells us almost nothing.

4. Every system it must talk to. CRM, payments, booking, ERP, email platform, ticketing. Include ones you are planning to add — architecture decisions depend on them.

5. Who maintains it after launch. A team with a developer and a team with one part-time marketer need different builds. This single answer changes the entire technology recommendation, and is usually what settles headless versus traditional CMS.

6. Budget range and deadline. Withholding budget does not get you a lower price; it gets you proposals aimed at the wrong tier. A range is enough — typical ranges are here if you need a starting point.

What to leave out

  • Prescribed technology, unless you have a real constraint. "Must be WordPress" when you needed a web app narrows you to the wrong shortlist — that decision deserves its own conversation.
  • Feature lists copied from a competitor. Describe the outcome and let people propose how.
  • Legal boilerplate in the first round. Save it for the shortlist.

Five questions that reveal a good agency

Ask every respondent:

  1. What did you not include, and why? A proposal with no exclusions has not been thought through.
  2. What is the riskiest part of this project? Anyone who says "nothing" has not read the brief.
  3. What will you need from us, and when? Projects slip on client-side content and approvals more than on development.
  4. Who actually does the work? Meet the people, not the sales team.
  5. What happens after launch? Handover, documentation, support terms, and who owns the code and accounts.

That last one is worth pushing on. Ownership of the repository, domain, hosting, and analytics should be yours in writing.

A structure that works

1. Who we are, and what the business does
2. Why we are doing this now (the one-sentence goal)
3. Current state: platform, traffic, known problems
4. Page types and any must-have functionality
5. Integrations, present and planned
6. Who maintains it after launch
7. Budget range and target date
8. How you will decide, and by when

Two to four pages. That is genuinely enough.

Working on one now? Send it over — we will tell you what is missing before you send it to anyone else, whether or not you shortlist us.

Keep reading