When an RFP helps, and when it does not
An RFP is a way of running a fair comparison. It suits projects large enough to justify several companies' time, organizations that must show a documented selection, and buyers who know what problem they are solving. It works poorly when the problem is still vague, because companies then price their own guesses and the replies cannot be compared.
An RFP is a good fit
- The problem and the goal are agreed internally
- A budget range and a decision maker exist
- You intend to compare three or four companies
- Procurement rules require a written process
Consider another route first
- You are still deciding what to build
- The project is small enough for a conversation and a quote
- You already know who you want to work with
- Nobody internally has time to answer questions
If you are in the second column, a paid discovery phase with one company is often a better start. It produces the clarity an RFP needs, and you remain free to tender the build afterwards.
What a software RFP should contain
| Section | What to write | Why companies need it |
|---|---|---|
| Background | Who you are and what prompted the project | To judge fit and understand the stakes |
| Problem and goal | What is not working, and what success looks like | To propose a solution instead of quoting a list |
| Users and workflows | Who will use it and the main things they do | The core of the estimate |
| Scope | What is in, what is out, what is undecided | To price the same project as everyone else |
| Existing systems | What must be connected, replaced or kept | Integration is where estimates go wrong |
| Constraints | Deadlines, budget range, technology, security, legal | To avoid proposals you could never accept |
| Process | Timetable, how to ask questions, how you will decide | To plan their effort and take it seriously |
| Questions | The same questions for every company | To make replies comparable |
What to leave out
Long RFPs deter good companies and reward those with the most time for paperwork. Three habits make documents longer without making proposals better.
- Prescribing the solution. Screen-by-screen specifications written before design remove the room for a better idea. Describe the work and the outcome.
- Generic questionnaires. Dozens of standard questions about company policies produce boilerplate. Ask the few questions whose answers would change your decision.
- Hidden budgets. Withholding the budget range does not get you a lower price. It gets you proposals for different sizes of project, which cannot be compared.
- Unpaid design work. Asking for mock-ups or prototypes as part of a proposal favours companies that guess well over companies that ask well.
An RFP template you can copy
Replace each prompt with your own text. Two or three sentences per item are usually enough. Leave an item in and write not yet decided where that is the truth.
Software development request for proposal
Template1. About us
Organization, what we do, and the team responsible for this project
Why this project, and why now
2. Problem and goal
What is not working today, with a concrete example
What we want to be true when the project is finished
How we will measure success
3. Users and workflows
Each kind of user and roughly how many
The main workflow, step by step
The exceptions that cause the most trouble today
4. Scope
In scope for the first release
Wanted later
Out of scope
Not yet decided, and what the decision depends on
5. Existing systems and data
Systems this must connect to, and how they can be reached
Systems this replaces, and the data to be carried over
6. Constraints
Deadlines and what drives them
Budget range
Technology, hosting, security or legal requirements
7. What we ask you to provide
Your understanding of the problem, in your own words
Your proposed approach and what you would build first
The people who would do the work, and their roles
How the project would run, and how we would see progress
Price, how it is built up, and what would change it
Assumptions, exclusions and risks
Costs after launch: hosting, licences, support
Two references for comparable work
8. Process
Date questions are due, and how to send them
Date proposals are due, and in what format
How proposals will be evaluated, with the criteria
Date of decision, and who decides
Contact person
A worked example
Part of an RFP for a membership system
This example is invented to show the level of detail that works. A professional association is replacing a membership database, and these are three of its answers.
- Problem and goalRenewals are handled by email and a spreadsheet. Members cannot see their own status, and staff spend the renewal season answering the same questions. When the project is finished, a member can renew, pay and download a certificate without contacting us.
- Not yet decidedWhether event booking belongs in the first release. It depends on whether the current events tool can be connected. We would like your view.
- Budget rangeWe have approval for a first release within a stated band, and expect to fund later phases separately. Proposals above the band will be read, and should say what could be removed to fit.
The association receives four proposals that all address renewals first, all comment on event booking and all sit in a comparable range. Two companies ask whether the events tool has an interface, which tells the association who read the document closely.
Run the process so good companies take part
- 01
Shortlist before you send
Invite three or four companies whose past work resembles your project. A wide mailing produces thin replies, and serious companies decline when they hear how many were asked.
- 02
Offer a conversation
Give each company a call to ask questions before they write. Share any answer that changes the scope with all of them, so nobody has an advantage.
- 03
Allow enough time
A thoughtful proposal for a substantial project takes real effort. A very short deadline gives you recycled documents.
- 04
Score against stated criteria
Use the criteria you published. Our guide to evaluating software development proposals explains how to line the replies up.
- 05
Tell everyone the outcome
Let the companies you did not choose know, with a sentence on why. It costs little, and you may want to approach them again.
Check the RFP before you send it
RFP checklist
0 of 10 checkedWhat to do next
Copy the template and fill in sections two and three first. If those are hard to write, the project needs more internal agreement before any company can help, and our custom software requirements builder is a quick way to get there.
When the RFP is ready, we would be glad to receive it. Send it through the contact page, and expect questions from us before a proposal.
Common questions
How long should a software RFP be?
A few pages for the core document, with detailed material such as existing process descriptions or data samples attached separately. If the main document runs much longer, it probably prescribes the solution or repeats standard questions. Companies read short documents carefully and long ones selectively, so brevity improves the quality of what comes back.
Should we include our budget in the RFP?
A range is strongly advisable. Software can be built at many levels of scope and finish, and without a range each company chooses its own level. You then receive proposals that cannot be compared. Stating a range does not prevent a company from proposing less, and you can ask each one what it would add or remove at the edges of the range.
How many companies should receive the RFP?
Three or four, chosen for relevant experience. That gives a real comparison while keeping each company's chance high enough to justify a careful reply. Sending to many more usually lowers quality, increases your reading time and makes follow-up conversations impractical.
What is the difference between an RFP, an RFI and an RFQ?
A request for information asks companies about their capabilities, usually to build a shortlist. A request for proposal asks how they would solve your problem and what it would cost. A request for quotation asks for a price on a specification that is already fixed. For custom software the proposal is normally the useful one, because the approach matters as much as the price.
Can we ask for a fixed price in an RFP?
You can, and for well-defined work it is reasonable. Where much is still undecided, a fixed price will either include a large allowance for risk or lead to disputes later. A common arrangement is a fixed price for a discovery phase or first release, with later work priced once more is known. Ask each company to explain its recommended structure.
