The request for proposal process is broken for bespoke software because it asks suppliers to put a price on work that none of them has been allowed to examine. A request for proposal, or RFP, is a document sent to several suppliers that sets out requirements and invites written, priced bids, which are then scored. For software written to order, the bids are guesses, the scores reward the writing of proposals, and the buyer ends up comparing prices for different things. A shorter process built around a one-page brief, real conversations and a paid investigation gives a better result in less time.
Where a request for proposal works
The method is not at fault everywhere. It works when the thing being bought can be fully described in advance and the bids can be compared line by line: vehicles, laptops, cleaning contracts, or licences for a packaged software product whose features are already known.
It is also required in some settings. Public bodies buy under procurement law, which sets its own procedures. In most of the UK that is now the Procurement Act 2023, which came into force on 24 February 2025. This article is written for private companies, which are free to choose how they buy. If you are bound by rules of that kind, or by a funder’s or a parent company’s policy, the section on running a better RFP further down is the part to read.
Why it fails for bespoke software
The requirements are written before anyone has investigated. The document is usually drafted inside the business, often as a long list of features. It describes a solution the authors have imagined, when what a supplier needs to understand is the problem. The things that decide the size of the job, such as the condition of the existing data, the systems to be connected and the rules staff apply without thinking, are rarely in it.
Conversation is restricted. To keep the contest fair, questions are submitted in writing and the answers are sent to every bidder. A supplier cannot sit with the people who do the work, look at the data or try the old system. The original version of this article compared it to asking doctors to quote for curing a headache without an examination, and the comparison still holds.
The price comes first. Each bidder has to name a figure for something it has not seen. The bidder that assumes the least quotes the lowest and tends to win. The gap between the assumption and the reality then comes back as change requests, or as a project that stalls. We describe the pattern in our article on when fixed-price software development works.
Bidding is expensive, so good suppliers decline. A full response takes days of senior time with an uncertain chance of winning. Suppliers with plenty of work are, in our experience, the ones most likely to pass, and those who do bid recover the cost of bidding in their prices.
The scoring measures the wrong thing. A proposal shows how well a company writes proposals. The people who present it are often not the people who would do the work.
It takes a long time. Writing the document, allowing a response period, scoring, shortlisting and holding presentations can occupy months, during which the problem the software was meant to solve carries on.
What to do instead
The alternative keeps the discipline of an RFP, which is that every supplier gets the same information and is asked the same questions. It drops the pretence that a price can be named before anyone has looked.
1. Write a one-page brief
Describe the problem and what it costs the business, who will use the system, the five things it must do on its first day, what it must connect to, the data to be brought across, and any deadline with the reason for it. Include a budget range. Buyers often hold this back for fear of anchoring the price, but a supplier that knows the range can tell you at once what is realistic within it. Our project planning worksheet produces a brief of this kind.
2. Shortlist three or four suppliers on evidence
Look for work of a similar kind and size, clients you can speak to, and a clear statement of who would do the work. Three or four is enough. A longer list costs every bidder more and tells you little extra.
3. Talk to each of them
Give each an hour or two with the person who knows the process. Judge them by the questions they ask. A supplier that asks about your data, your exceptions and what happens when things go wrong is already doing the job. One that talks mostly about itself is showing you what the project would be like.
4. Ask each the same questions
Ownership of the code, who does the work, how changes are priced, what happens after launch and what you would receive if you left. Write the answers down. Our list of questions to ask a software supplier has a table for comparing them.
5. Pay for a short investigation
Choose the supplier you prefer, or two if you cannot decide, and pay for a short piece of work that examines the unknowns and produces a written scope: what the system will do, the assumptions, the exclusions and the checks it must pass. This stage is often called discovery. Agree beforehand that the output is yours to keep and to take elsewhere.
Paying matters. It gets you the supplier’s proper attention, and it lets you see how the supplier works before you commit to the larger sum.
6. Ask for a price against that scope
With a written scope, a supplier can commit to a fixed price, and if you ask a second supplier to quote against the same document, the two figures describe the same thing. Our fixed-price page explains how scope, price and acceptance checks are agreed before work starts.
If you have to run an RFP
Sometimes the board, a funder or a group policy requires a formal competition. It can still be made to work better.
| The usual practice | A better one |
|---|---|
| A long list of required features | The problem, the users and the outcomes needed |
| Questions in writing only | A session for each bidder with the people who do the work |
| No access to systems or data | A sample of the data and a look at the current system |
| A fixed price for the whole project | A price for the discovery stage and an indicative range for the build |
| The budget withheld | A budget range stated |
| Open to all comers | Three or four invited bidders |
| Scored on the written proposal | Scored on evidence: references, sample documents, the delivery team in the room |
Keep the document short, and tell unsuccessful bidders why they lost. Suppliers remember which buyers treat the process seriously, and that affects who bids next time.
A check before you start
Before sending anything to a supplier, try to state the problem in two sentences with no mention of software: what goes wrong today, and what it costs. If you can, you have the opening of a brief, and a conversation with three suppliers will get you further than a tender would. If you cannot, the next step is to talk to the people who do the work, because no procurement method will settle it for you.