Buyer Resource
RFP & Vendor Evaluation Guide
Two real, related problems: writing a request that gets you accurate quotes, and evaluating the vendors who respond on more than just the bottom-line number.
Writing the RFP: what actually gets you an accurate quote
- —State the real problem, not just the solution you've already decided on — a vendor who understands the problem can flag a better approach than the one in your draft.
- —Be explicit about what's already fixed (existing systems it must integrate with, non-negotiable deadlines) versus what's still open to the vendor's judgment.
- —Include real data about scale — how many users, how much data, how much transaction volume — vague scale ('a lot') is the single biggest cause of wildly inconsistent quotes across vendors.
- —State your actual budget range, even approximately. Withholding it doesn't get you a better price — it gets you quotes that don't reflect what you can actually spend, wasting everyone's time.
- —Specify what 'done' looks like — acceptance criteria, not just a feature list — so vendors are quoting the same finish line.
Evaluating responses: what to weigh beyond the price line
- —Does the quote reflect that they understood your actual problem, or did they quote a generic version of the feature list back at you?
- —Is the price a single number with no scope attached, or is it tied to a written scope you could hold them to?
- —Did they ask clarifying questions before quoting, or price it sight-unseen? A vendor who quotes complex work with zero questions is either very experienced with this exact problem or not looking closely.
- —What happens if the built system needs to change after launch — is there a real handover/ownership story, or does everything stay dependent on them?
- —Check for a fixed price with no scope boundary at all — that's usually a sign the vendor plans to make it up in change orders, not a sign of confidence.
Red flags worth weighing seriously
- —A quote significantly below every other response with no explanation for the gap — usually means a different (thinner) scope, not a better deal.
- —No willingness to put the scope in writing before starting — verbal understandings don't hold up when there's a disagreement later.
- —No answer, or a vague answer, to 'what does handover actually include' — a real answer to this question is a strong signal of whether you'll own what gets built.
If you're weighing whether your project's requirements are settled enough to RFP as a fixed spec, or likely to evolve once real work starts, see Agile vs. Waterfall before writing the RFP — it changes what you should actually be asking vendors for.
Related
FAQs
Should I include a budget range in the RFP?
Yes — an approximate range gets you quotes that actually reflect what you can spend, rather than a scattered set of numbers that don't map to your reality. Withholding it doesn't protect you; it just makes responses harder to compare.
How many vendors should I send an RFP to?
Enough to compare real approaches (3-5 is typical), not so many that reviewing responses becomes its own project. A shorter, well-qualified list usually produces better responses than a mass blast, since vendors invest more effort when they believe they have a real shot.
What if vendor quotes vary wildly for the same RFP?
That's common, and it usually means the RFP itself left too much open to interpretation (scale, scope boundaries, what 'done' means) rather than that vendors are randomly pricing. A wide spread is a signal to tighten the RFP, not just pick the middle number.
Have a project in mind?
Tell us what you're trying to automate or build — we'll reply with next steps, not a sales pitch.