An RFP can solicit proposals. It cannot tell you what you actually need.
A web team knows the current site is a problem — editors can’t update content without IT, accessibility hasn’t been touched in years, leadership keeps asking about AI-powered search and the answer is always “not with this system.” So the team writes an RFP describing the pain and asking vendors to fix it.
What they don’t know is what the fix should cost, what scope is realistic, or what to ask for. And the RFP doesn’t help them figure any of that out. It just sends the question to 10+ agencies and waits for answers that will range anywhere from $20,000 to $400k.
That spread isn’t a typo. It’s an honest description of where bids land, depending on platform, scope, and how the agency interprets the request. You could average the bids and call that your budget, but averaging ten guesses doesn’t get you to the right number — it just gets you to the middle of ten guesses. Until you know what your project actually needs, more proposals won’t tell you. They’ll just give you more opinions.
The Budget Section Is Where Most RFPs Quietly Sabotage Themselves
The most common piece of bad RFP advice in this sector is “don’t share your budget — see what vendors propose.” It’s everywhere, and it doesn’t work.
A vendor cannot tell you how to approach a project without knowing what there is to work with. A redesign built for $100,000 looks nothing like a redesign built for $350,000 — different platform decisions, different scope, different team. Asking ten agencies to guess what you can afford produces ten incomparable proposals and no useful signal about which one is right for you.
The reasoning behind budget secrecy is that vendors will “pad to the number.” Some might. But a vendor who pads when given a number is a vendor who would have padded anyway, and you’d rather find that out in the proposal than after the contract is signed. Share the budget. The proposals you get back will be sharper, more directly comparable, and a better read on which firms actually understand the problem.