The RFP landed in my inbox on a Tuesday afternoon: 68 questions, a security appendix, and a submission deadline nine days out. I had never written one, had no proposal team, and spent the first four hours reading questions instead of answering a single one.
That's the moment most founders lose their first RFP, not because their product is wrong for the deal, but because they treat every question as equally urgent and start typing before deciding whether the deal is even worth the week it's about to eat.
The real cost of saying yes to an RFP
The average RFP runs somewhere between 60 and 80 questions, and teams that actually measure this put real answer time at 20 to 25 minutes per question once you count finding the right internal source, drafting, and getting it reviewed. Run that math on a 68-question RFP and you're looking at roughly 25 to 28 hours of work, before you've formatted a single page, spread across a week you were probably planning to spend closing the three deals already in your pipeline. An RFP isn't a form. It's a part-time job with a hard deadline, and the first decision you make about it is whether it's worth taking at all.
In my case: 68 questions, six of them needing answers from an engineer I didn't want to interrupt for a deal we weren't sure we'd win, and one asking for a SOC 2 report we didn't have yet. I answered all 68 anyway, out of order, starting with whichever were easiest instead of whichever mattered, and submitted with an hour to spare. We didn't win. Looking back at that submission months later, the reason wasn't the product. It was the response: generic, defensive on the security section, and missing a single sentence about why we were the right fit for what they'd actually asked in question one.
Qualify before you write a single word
Every RFP that lands in your inbox came out of a real procurement process, which makes it feel like an obligation to respond. It isn't. Before opening the document, answer three questions:
- Do you already have a champion inside the buying committee, someone who can tell you why this RFP exists and what's actually driving the decision? If the RFP is your first contact with the account, your win rate on cold RFPs is a fraction of what it is on relationship-led ones.
- Is the budget and timeline real, or is procurement running this to satisfy a three-bid policy while an internal favorite is already picked? Ask directly: "Is there an incumbent or internal favorite for this?" A dodge is your answer.
- Does the deal size justify 25-plus hours of founder time this week? A $15k ACV RFP that eats your whole week has a worse return than the same hours spent on outbound to your ten best target accounts.
If you can't answer yes to at least two of these, send a short no-bid note and move on. A polite decline costs you nothing. A rushed, generic response to a deal you were never going to win costs you a week, and it trains procurement teams that you're an easy invite next time, whether or not you can actually win.
Build the reusable core before you need it
The founders who respond to RFPs fast aren't faster writers. They're not starting from zero. Before your next RFP arrives, build four reusable sections you'll reuse in every response with minor edits:
- Company and product overview — two paragraphs, no jargon, written for someone hearing about you for the first time.
- Security and compliance answers — SOC 2 status, data residency, uptime SLA, and access controls, written once and kept current.
- Implementation and support — onboarding timeline, support hours, and escalation path.
- Reference customers — two or three logos with a one-line result each, cleared in advance to be named in a proposal.
With that library built, a 68-question RFP stops being 68 blank answers. Usually 40 to 50 of them map almost directly to your reusable content, leaving 15 to 20 that are genuinely specific to this buyer. That's the fraction of the work that actually needs your attention this week, not the whole document you'd otherwise be facing from a blank page.
Structure your answer around their questions, not your pitch
The instinct is to lead with why your product is great. Procurement doesn't read it that way. Mirror their document's structure exactly, in their numbering, and answer the literal question asked before adding context. A skipped or reordered question reads as either not paying attention or hiding something, and either one gets you cut before a human ever compares features.
Put your differentiation in exactly one place: a short executive summary at the top, three sentences on the specific outcome you'd deliver for this buyer, tied to something they told you matters to them. That's the only spot in the document where you get to sell. Everywhere else, you're answering.
What to do this week
If an RFP is sitting in your inbox right now, run the three qualify questions before you open the attachment. If it's a real opportunity, block two hours today to draft your executive summary and pull your reusable sections into a first pass, then spend the rest of the week on the buyer-specific slice that's left. If nothing's in your inbox yet, build the four reusable sections above this week anyway. The next RFP will arrive with a deadline you didn't choose, and the founders who've already done the boring work are the ones who actually have time to win it.