How to write a software development RFP that gets honest bids

We get a lot of requests for proposals. Most of them have the same problem, and it is not a small one. The document asks us to commit to a fixed price and a fixed date for a product that nobody has actually scoped yet. It reads as careful and responsible, the kind of thing a good buyer is supposed to do. But it puts every honest team in a difficult position, and it rewards the teams you least want to work with. If you have ever sent out an RFP and gotten back numbers that differ widely and wondered which one to trust, this is usually why.

Here is how we think about writing an RFP that gets you real answers instead of a set of guesses presented as quotes.

The fixed price on an unscoped problem is the main cause of the problem

Start with the single mistake that causes most of the others. You ask for a firm price and a firm timeline before anyone, including you, knows exactly what is being built.

For work you have done before, a fixed price is fine. If you are asking someone to build the same landing page they have built many times, they can price it accurately because there are almost no unknowns. But most RFPs are not for the known thing. They are for the new thing, the product or the feature that is the reason you are hiring outside help at all. And the new thing is, by definition, full of things nobody has figured out yet.

When you demand a firm number on that, you force a choice on every team that bids. The honest teams add extra to the number, sometimes a large amount, to cover all the things they can see coming and cannot see clearly. The dishonest teams quote low to win the work, then charge you the difference later as change orders once you are committed and it is too late to switch. So your "competitive" set of bids is really a mix of high-but-honest and low-but-misleading, and the RFP gave you no way to tell them apart. This is the same idea we wrote about in what custom software actually costs: the price of anything new is driven by how much you still do not know, and pretending you know it does not make the unknown go away. It just hides it until you get the bill.

Describe the problem and the outcome, not the solution

The most useful thing you can put in an RFP is a clear description of the problem you are solving and what success would look like. The least useful thing is a detailed spec of the exact solution you have in your head.

We see this constantly. An RFP arrives with pages describing the specific screens, the specific database design, the specific technology, all decided before a single engineer who will do the work has looked at it. What that does is turn every bid into a bid on your guess. You have quietly taken the hardest and most valuable work, deciding what to build and how, and done it yourself, badly, before hiring the people you are paying for their judgment. If your guess is wrong, and for new products it usually is in part, you have now aimed the whole bidding process at the wrong solution.

Do the opposite. Tell the bidders who has the problem, what the problem costs them today, and what a good outcome would be. "Our support team spends four hours a day copying data between two systems, and we want that to be minutes" is worth more than three pages specifying the sync tool you imagine building. Give them the outcome and the constraints, and let them propose the how. The teams worth hiring will come back with a better how than the one you would have written, because thinking about the how is the thing they are actually good at. We wrote about this instinct from the client side in knowing what to build: the goal is to keep the outcome fixed and the solution open to change.

Name the unknowns out loud

Here is the step that separates a useful RFP from a hopeful one. Instead of pretending the plan is settled, write down what you do not know yet.

It feels wrong to admit uncertainty in a document meant to show confidence. Do it anyway. If you are not sure whether the integration with your billing provider is simple or difficult, say so, and ask each team how they would find out. If you do not know whether your users actually want the feature the way you imagine it, say that too. Naming the unknowns does two things. It tells the bidders where the real risk is, so their numbers reflect the actual work instead of an imagined version of it. And it shows you the teams who know how to handle uncertainty, because a good team will respond with a plan to reduce the unknown early, not a promise to ignore it.

A team that reads "we are not sure how hard the billing integration is" and responds "we would build a small test against your billing provider in the first week to find out before committing to the rest" is showing you something a price alone never could. That is a team that has delivered real work. The team that reads the same line and just sends a confident single total is telling you they either did not read it or do not know what they do not know.

Ask how they price the first small piece

Rather than asking for one big number on the whole build, ask how each team would approach and price the first small, real piece of it.

The strongest engineering teams do not build the whole thing and reveal it at the end. They release in small, frequent steps, because a small piece that goes wrong is easy to see and fix, while a giant release that goes wrong hides the problem inside a hundred changes at once. This is one of the most consistent findings in the long-running DORA research on how software teams actually perform: releasing in small increments correlates with lower failure rates, not higher. An RFP that asks "how would you scope and price the first two weeks so we both learn whether this is on track" gets you a proposal from a team that works this way. An RFP that only asks for the total gets you a team happy to work for six months without showing you anything.

This also protects you. Committing to the first small piece is cheap, and it tells you far more about whether you want to work with this team than any well-presented proposal. You see how they scope, how they communicate, and whether the thing they deliver matches what they promised, all before you have committed the whole budget to them.

Keep it short and make comparison fair

Two smaller things that matter more than they look. Keep the RFP short, and set up a fair comparison.

Short is better than long. A serious team can answer a few focused pages that make the problem and the constraints clear. A fifty-page template full of boilerplate mostly hides the two or three facts that actually decide the price, and it signals that you value process over thinking. Say what the problem is, what success looks like, what the hard constraints are (a maximum budget, a real deadline, a required integration), and how you will choose. Then stop. If you want a ready-made structure to start from, we built one: a software development RFP template with the eight sections above already laid out as fillable headings.

For comparison, ask every team the same clarifying question and watch who asks good questions back. Compare what each bid includes and how it treats the unknowns, not just the total price, because the cheapest bid usually wins by assuming the least, which means the gap reappears later as work nobody priced. The bid that questions your assumptions and proposes a way to reduce risk is usually the one that has actually thought about your problem. If you want a clearer view of which teams to avoid, we listed the warning signs in red flags when hiring a software development agency, and the difference in mindset you are really looking for in software development partner vs. vendor.

What you are really buying

Look at the whole process and its point becomes clear. You are not buying a price. You are buying judgment under uncertainty, from a team that will make hundreds of small decisions you never see, on a problem that will change as you learn. An RFP written to fix a number on an unscoped problem measures none of that. It measures who is willing to make the boldest promise, which is exactly the wrong thing to reward.

Write the RFP to reveal judgment instead. Describe the problem and the outcome, name what you do not know, ask how they would test the first small piece, and keep the whole thing short enough that a good team will actually engage with it. Do that, and the bids you get back stop being guesses and start being a real look at how each team thinks. When we bid on work like custom software development or a full product build, the RFPs we take most seriously are the ones written this way, because they let us give an honest answer instead of an inflated one. And an honest answer is the only kind worth comparing.

One addition to any RFP written today. Ask each bidder two questions in writing: what proportion of the delivered code will be AI-generated, and what their review process is for it. You are not looking for a low number. Generated code is fine and is where the industry is going. You are looking for a supplier who answers plainly and can describe a review step with a person's name attached to it, because the ones who cannot are the ones whose bid is cheap for a reason you will discover later.

Sources

• DORA, Accelerate State of DevOps research: https://dora.dev/research/
• McKinsey and University of Oxford (2012), "Delivering large-scale IT projects on time, on budget, and on value": https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value