The first RFP I said yes to took eleven days of my team's time and we lost anyway. The second one took four days, cost a fraction as much, and we won. The difference wasn't luck. It was that I finally sat down and did the math before saying yes, instead of after saying no to something else.
Most founders treat the RFP decision as a gut call: big logo, exciting logo, must chase it. Nobody adds up what chasing it actually costs. A typical enterprise RFP response runs $5,000 to $50,000 in fully-costed effort, according to Steerlab's breakdown of RFP response costs. Here's the arithmetic I wish someone had handed me before my first one.
What an RFP response actually costs
Start with hours, not vibes. A mid-complexity B2B SaaS RFP, thirty to eighty questions, a security section, a pricing table, maybe a live demo, typically pulls in three to five people: you or your head of sales, an engineer or two for the security and technical questions, someone for the writing and formatting, and whoever owns pricing.
On my second RFP I tracked it properly. Five people, forty-one combined hours, spread across four days. At a blended loaded cost of roughly $90 an hour for an early-stage team, that's about $3,700 in direct labor. That number alone surprises most founders. It's not the eye-catching enterprise figure you read about in RFP software marketing, but it's also not nothing when you're eight people and burning runway.
Then there's the cost nobody puts in the spreadsheet: opportunity cost. Those same forty-one hours weren't spent on the three warm deals already in your pipeline, the onboarding calls that reduce churn, or follow-ups that don't require anyone issuing you a fifty-page questionnaire. If your engineer spent six hours on the security section instead of shipping a feature a paying customer is waiting on, that's a real cost even though it never shows up on an invoice.
The math that decides whether to respond
Here's the version of the calculation I actually use now, and it takes about five minutes:
Expected value = (Contract value × Win probability) − Response cost
Say the deal is worth $80,000 in first-year contract value. If you're responding cold, with no prior relationship and no champion inside the buying committee, your realistic win rate on an inbound RFP is closer to 10-15% than the 40% you're hoping for. At 12%, expected value is $9,600. Subtract your $3,700 response cost and you're left with $5,900 of expected upside, thin, but positive, so it can make sense if the deal also opens a new vertical or a reference-able logo.
Now run the same formula on a $30,000 deal with the same 12% win rate. Expected value is $3,600. Subtract the $3,700 cost and you're underwater before a single dollar of onboarding or support cost is counted. That's the RFP you decline, politely, and immediately, not because the logo isn't nice, but because the arithmetic says no.
The variable that swings this calculation more than any other is win probability, and founders consistently overestimate it. If you weren't invited by name, if there's an incumbent already in the account, or if procurement sourced you from a directory, your real win rate is closer to 8-15%. If you have a warm champion who asked for this RFP specifically because they want you, it can be 40% or higher, and that's the single fact most worth confirming with a phone call before you commit a single engineering hour.
Cutting the cost instead of skipping the deal
Once I started tracking cost per RFP, the more useful move usually wasn't respond-or-don't, it was cutting the cost of responding without cutting the win rate.
- A living answer library for the twenty questions every RFP asks (security posture, uptime SLA, data residency, integration list, pricing tiers) turned what used to be a two-day writing task into a two-hour editing task. I built mine after the third RFP; it should have existed after the first.
- A hard qualify-first rule, no engineering hours committed until you've confirmed budget, timeline, and decision-maker access, cut our average response cost by close to 40% because half our old responses were going to deals that were never going to close, RFP or not.
- A cap on response time itself. If a response is taking longer than three days for a deal under $100k, that's usually a sign the deal doesn't warrant the investment, not a sign you need to work harder.
If you haven't run the go/no-go test yet, that decision should happen before the cost math, not after; here's the 3-question filter worth applying first.
Frequently asked questions
How much does a typical RFP response cost a startup?
For an early-stage team, direct labor usually falls between $2,000 and $8,000, depending on how many people are pulled in and how many hours the security and technical sections require. Larger enterprise RFPs with formal security questionnaires can run well past $15,000 once every contributor's time is counted.
What win rate should I assume for a cold inbound RFP?
Absent a named champion inside the buying committee, assume 8-15%. With a warm champion who requested you specifically, 40% or higher is realistic. The gap between those two numbers is usually the difference between a good bet and a guaranteed loss.
Should opportunity cost factor into the decision, not just direct labor?
Yes. Direct labor is the easy number to calculate; opportunity cost is usually larger and easier to ignore. If the hours would otherwise go toward active pipeline or product work with clearer ROI, weight that against the RFP before committing the team.
Before your next RFP lands in your inbox, do the five-minute version of this math: multiply contract value by a realistic win rate, subtract your team's actual hourly cost times expected hours, and look at what's left. If the number is small or negative, decline fast and spend the time on pipeline you can actually influence. If it's clearly positive, respond, but track the hours this time, because the number you assume going in is almost never the number you'd calculate if you actually added it up.