RFP for software development: why most non-technical founders are using the wrong instrument
A founder we talked to last quarter sent the same 11-page RFP to five software studios. Pre-seed company, two enterprise pilots signed, a six-week window to ship a working v1 to the first paying customer. The RFP was a template she’d downloaded from a procurement blog: company background, project goals, scope of work, technical requirements, evaluation criteria, deadline. It looked professional. It looked like the responsible thing to do.
Three studios didn’t respond. The two that did sent back bids that were $90K apart on the same scope. Neither asked her the question that mattered, which was whether she actually needed everything she’d written down. She picked the cheaper one. Six months later she was on her third project manager and her customer was using a spreadsheet.
This is what an RFP for software development looks like when the instrument doesn’t match the work. It’s also what most articles ranking on this query miss: the question isn’t how to write the RFP, it’s whether the RFP is the right thing to write at all.
What an RFP for software development actually is
An RFP, or Request for Proposal, is a formal procurement document. A buyer issues it to a known shortlist of vendors describing what they need built, by when, under what constraints, and how the bids will be evaluated. Vendors respond with a structured proposal: scope, team, timeline, price, references. The buyer evaluates the responses against the criteria in the document and picks the winning bid.
The instrument exists because procurement at scale is hard. When a Fortune 500 IT department buys a CRM, a regulated agency contracts an integrator, or a hospital system selects an EHR, the RFP enforces three things: an even playing field for vendors, a paper trail for the decision, and a defined contract scope so the buyer isn’t holding the bag when the project goes sideways. For that kind of buy, the RFP is the right document.
For a non-technical founder commissioning a custom software build at pre-seed, seed, or Series A, those three properties don’t apply. The vendors are a tight community, not a procurement market. There’s no audit committee to satisfy. And the scope isn’t actually defined yet. It can’t be, because the whole reason the founder is hiring out is that they don’t know what to build down to the requirement level.
Why founders reach for an RFP anyway
There are usually three triggers. None of them is “an RFP is the best instrument for this work.”
The first is inheritance. The founder spent ten years in finance or consulting or a senior corporate role before starting the company. Every procurement decision in their old life used an RFP. It’s the muscle memory for “we are spending real money and need to be careful.” When the budget is $150K and the project will outlive the next funding round, an RFP feels like the adult version of “shopping around.”
The second is fear of being taken. ICP pain #2: every freelancer has burned them. Friends raised pre-seed, paid an agency $200K, and got a half-working app. The founder reaches for an RFP because the document feels like protection: clear scope, clear deliverables, clear penalties.
The third is investor optics. A board member or advisor told them to “get three quotes.” A CFO who hasn’t worked in product before suggested formalizing the process. The RFP is the artifact that proves due diligence happened.
All three triggers are legitimate. The mistake is concluding that an RFP is the answer to any of them. Caution, protection, and due diligence at pre-seed look almost nothing like procurement at the enterprise.
Three problems with an RFP for early-stage custom software
Problem 1: the spec problem
An RFP asks the buyer to specify what they want built. Section 3 is always “Project Scope and Requirements.” For packaged software, this works: the buyer knows they want a CRM that does X, Y, and Z, and vendors price against those features. For custom early-stage software, the founder doesn’t know yet what they want. They know the customer pain, they know the business outcome they need, and they have a hypothesis about the first slice of the system. The whole point of working with a partner is to compress the distance between hypothesis and shipped product.
When the RFP forces the founder to write down 40 requirements they haven’t validated, two bad things happen. They overspecify, because empty cells in the requirements section look unprofessional. And vendors price against the overspecified scope, not the real problem. The 40 requirements become the contract, and any deviation becomes a change order. The founder has hardened a guess into a deliverable before talking to a single engineer.
The studios that recognize this (the good ones) would tell the founder to throw out the requirements section and start from the customer problem. They won’t tell her that inside the bid, because the bid format doesn’t have a slot for “your document is the wrong shape.”
Problem 2: the bid problem
RFPs collect bids. Bids get compared. The lowest qualified bid usually wins, sometimes adjusted for scoring weights the buyer set up in advance.
This works for commodity work. If you need ten thousand screws milled to ISO spec, the lowest qualified bid is the right answer, because the work is genuinely identical between vendors. Custom software is the opposite. The work is not identical. The studio that asks the founder five sharp questions about the problem and quotes a higher number is doing something the cheaper studio isn’t, but neither the RFP nor the bid format captures that difference.
Worse, the bid format selects against the studios you actually want to work with. The good ones either don’t bother responding (they’d rather have a 30-minute conversation than spend three days filling out a form) or they pad scope to protect themselves from the inevitable spec drift, which makes their bid look expensive. The studios that respond eagerly with low numbers are doing one of three things: optimistically underestimating to win the deal, planning to change-order their way to profitability, or treating the build as junior-team training. The mechanism selects for the wrong partners.
Problem 3: the relationship problem
The RFP frames the engagement as vendor and buyer. The vendor delivers; the buyer accepts or rejects. The contract enumerates penalties for missed milestones. The work is opaque between checkpoints. The buyer has visibility only at the gates the document defined upfront.
Custom software needs the opposite shape: weekly visibility, fast iteration, shared decisions on trade-offs the founder couldn’t anticipate at week zero. A studio that’s a real partner says “we should rethink milestone three based on what we learned in milestone two.” A vendor under an RFP-derived contract says “milestone three is in scope; if you want to change it, here’s the change order.” Same studio can do either depending on the contract underneath. The RFP almost always produces the second shape.
This is why source code escrow, lock-in clauses, and elaborate exit provisions show up in agency contracts so often: they’re the protection mechanisms a vendor relationship demands. When the relationship is a real partnership, most of them are unnecessary.
What to send instead: the five-paragraph partner brief
Replace the RFP with a one-page document. Five short paragraphs. Send it to two or three studios you’ve already shortlisted from references, not five you found on Google.
Paragraph 1. The business problem in plain language. What is your customer paying you to fix? Two or three sentences, no jargon. “Independent insurance brokers in São Paulo spend 6 hours per policy reconciling commission statements from 14 carriers. We charge them a subscription to do it in 10 minutes.” Better than 40 requirements. The studio learns more from this paragraph than from the entire requirements section of any RFP template.
Paragraph 2. The first thing you’d ship. What’s the smallest version of the system that gets one paying customer to use it for real? Not the MVP as branded, the first version you’d be proud to put in front of a paying customer. See our piece on how to brief a developer for a startup for the framing. One paragraph, three or four core capabilities. If you can’t write this paragraph yet, the discovery work isn’t done.
Paragraph 3. Your budget range. A real number, not an anchor low one. “We’ve allocated $80K to $120K for the first build.” Or: “We have $60K and need to know what we can ship for that.” Withholding the number doesn’t get you a better deal; it gets you bids calibrated against the wrong frame. If you don’t know the right range, our piece on fixed-price versus time-and-materials contracts covers the structure questions.
Paragraph 4. Your timeline and what’s driving it. “We need v1 in production by August 30 because our first enterprise customer’s pilot starts September 1.” The constraint is the real information. A timeline pulled out of the air (“we’d like to launch in Q4”) tells the studio nothing about what trade-offs you’re willing to make.
Paragraph 5. Three questions you’d like the studio to answer in writing. Not “tell us about your company.” Things like: Have you built something like this for a similar-stage company? Who specifically would be on this project, by name, and what’s their background? What’s the first thing you’d push back on in this brief? The third question separates partners from vendors faster than any other prompt.
A studio that can’t or won’t respond to that document in 48 hours isn’t a fit. A studio that responds with three sharp questions of its own is exactly the studio you want to keep talking to.
When an RFP actually is the right call
Three narrow situations, mostly outside the early-stage custom-software buy.
Buying packaged software. You’re picking a CRM, an ERP, a customer-data platform, an HRIS. The scope is defined by the product itself. The vendors are real procurement targets with sales teams that respond to RFPs as standard practice. The RFP works.
Regulated industries with procurement rules. Health systems, financial institutions over a certain size, government-adjacent buyers. Your contracts team will tell you an RFP is required and there’s no real argument against it. Use the instrument that fits the policy environment. Just understand it’s the policy that’s driving the document, not the nature of the work.
Genuinely commodity work with a finished spec. You already built v1, the system is in production, and you need a known scope of additional features that doesn’t require partnership-style discovery. The RFP is reasonable here because the work has actually become commodity. Most founders aren’t in this state and shouldn’t pretend they are.
If you’re not in one of those three buckets, the partner brief is the right document.
What to ask in the first conversation that no RFP will
The five-paragraph brief is the filter. The 30-minute first conversation is where the real selection happens. Four questions that no procurement document will pull out:
1. “Walk me through the last project you walked away from.” Studios that have never said no to a client are saying yes to everything. That’s the worst signal. The studios worth working with can name the engagement they declined and explain why.
2. “Who on your team would I be talking to in week 4 of the project?” If the answer is the founder or the salesperson, the team you saw in the pitch isn’t the team that’s building. A specific senior engineer’s name is the answer you want.
3. “What do you think is wrong with my brief?” A studio that says “nothing, looks great” is selling. A studio that points at paragraph 2 and says “I don’t think the first thing you’d ship is what you think it is” is doing the work in the conversation.
4. “What’s the smallest engagement we could start with?” Real partners propose a two-to-four-week scoping or discovery sprint before quoting the full build. Studios that quote $180K on the first call are guessing.
You won’t get those answers from a written RFP response, no matter how elaborate the evaluation rubric.
FAQ
What is an RFP in software development? A Request for Proposal is a formal procurement document that a buyer sends to vendors describing what they want built, the constraints, and how bids will be evaluated. It originated in enterprise IT and government procurement, where standardized vendor selection is required. The instrument works well for packaged-software buys and regulated procurement, and poorly for early-stage custom software where scope is still emerging. The Wikipedia entry on Request for proposal covers the formal definition and history.
Should I send an RFP to multiple software studios? For a custom build at pre-seed or seed, no. Send a one-page partner brief to two or three studios you’ve already shortlisted from references. The RFP-to-five-studios pattern selects for studios that win on bid-padding, not on craft.
What’s the difference between an RFP and an SOW for software development? An RFP is a procurement document used before vendor selection: you send it to multiple vendors, collect bids, and pick one. A Statement of Work is a contract document signed with the vendor you picked: it defines scope, deliverables, timeline, and price for the actual engagement. Many founders confuse the two because templates online conflate them. The RFP comes first if you use one at all; the SOW always comes after vendor selection.
Can I just use an RFP template I found online? You can. Most of them are written for enterprise IT procurement and will overspecify your project by an order of magnitude. If you decide an RFP is still the right instrument for your situation, gut the requirements section and replace it with a problem statement and a first-thing-to-ship paragraph. Better still, skip the template and send the five-paragraph brief.
What if a studio asks me to send an RFP? A few studios prefer the structured response process because it lets them route the proposal through their own internal pipeline. That’s a fair preference. Send the partner brief first and let them translate it into whatever internal artifact they need. If they insist the brief has to be in RFP shape before they’ll engage, that’s a small signal about how the engagement will feel. Process-heavy, vendor-shaped, slow to iterate. Read accordingly.
How long should an RFP for software development be? If you decide to send one, two pages. The five-paragraph brief in the format above, plus a half-page on evaluation criteria. Anything longer comes from the template and isn’t doing useful work. Procurement-grade RFPs run 20–40 pages because they have to clear policy and legal review. None of that applies to your build.
The instrument matters because it shapes the conversation. The RFP for software development was built for one kind of buy; almost nothing about it fits the buy a non-technical founder is making at pre-seed. Send the document that fits the work, not the one that looks most professional from the outside.