RFP template for software projects
Written from the receiving end. The sections that produce comparable bids, and the ones that waste everybody's month.
What the template covers
4 things that decide this
- 01An RFP built from a feature list produces bids you cannot compare, because each vendor assumed something different about the hard parts.
- 02Describe the outcome and the constraints. Let vendors propose the approach, then compare how they thought rather than what they listed.
- 03Four questions separate a production team from a demo shop: how they test, who operates it, what you own, and what they would cut first.
- 04Naming your constraints openly gets you better bids. Vendors price uncertainty, and a vague brief is priced as risk.
We read these, so we know which ones work
Most software RFPs arrive as a spreadsheet of features with a column for yes or no. Every serious vendor ticks nearly every box, so the sheet ranks nobody and the decision falls back to price.
The useful ones do something else. They describe what has to be true when the project is finished. They name the systems it must live with. They say plainly what is fixed and what is still open.
That shift changes the replies. A vendor who has done the work will ask about the awkward part of your process. One who has not will restate your requirements back to you in their own template.
- Outcome statedWhat is true when this is done
- Constraints namedSystems, rules, data, deadlines
- Approach openVendors propose, you compare thinking
- Same questionsEveryone answers the identical four
- Comparable repliesDifferences are real, not framing
A feature checklist skips the middle three, which is why its replies all look alike.
The eight sections, and what each one is for
This is the structure in full. The formatted version adds prompts and example wording for each section.
| Section | What goes in it | What it protects you from |
|---|---|---|
| 1. The outcome | What is measurably true when the project is done | A build that satisfies the spec and misses the point |
| 2. Who uses it | The roles, their volumes, and their worst day | Software designed for the demo user, not the real one |
| 3. What it must live with | Existing systems, data sources and the ones that cannot change | The integration nobody priced, found in week six |
| 4. Rules and constraints | Regulation, data residency, audit needs, approvals | A rewrite when a compliance requirement surfaces late |
| 5. What is fixed | The decisions already made, and why | Bids that re-litigate settled choices |
| 6. What is open | Where you want the vendor's judgement | Getting your own assumptions quoted back at you |
| 7. The four questions | Testing, operations, ownership, and what they would cut | Choosing on price between answers that were never alike |
| 8. How you will decide | The criteria, their weight, and the timeline | A long process that ends in a decision nobody can explain |
Four questions that rank vendors on their own
Ask every bidder the same four, and read the answers side by side. The differences will be large and they will not be about price.
Ask how they will know the system is still correct in six months. A production team describes a test suite that runs automatically on real cases. Ask who is on call when it breaks outside office hours, by name and role, and treat vagueness as the answer.
Then ask what you own at the end. Source code, prompts, models, data pipelines and infrastructure should all be yours in writing before work starts. Last, ask what they would cut first if the budget dropped by a third. A vendor who cannot answer has not thought about your priorities. One who offers to cut testing has just told you what they think testing is for.
- 01Give every vendor the same four questions in the same words, or the replies stop being comparable.
- 02Ask for one example of a system they still support, and who supports it.
- 03Say what is fixed. Vendors price uncertainty, and unspoken constraints get priced as risk.
- 04Keep the response format short. A long template rewards whoever has the biggest proposal team.
