How do I write a software RFP?
Describe the problem and the users, not a finished solution: what the software must do, the constraints it must meet, your budget range and timeline, and exactly how you will score the answers. Clear, scored questions get comparable proposals; vague ones get sales copy.
Last updated
What to include
- 1Background: your organisation, the problem and why now.
- 2Users and their key tasks, with the few workflows that matter most.
- 3Must-haves and nice-to-haves, kept separate.
- 4Constraints: systems to integrate with, compliance rules, hosting, accessibility, languages.
- 5Budget range and target dates, even if rough.
- 6What you want back: approach, team, plan, price model, assumptions and references.
- 7How you will score answers, with weights, and the timeline for questions and decisions.
Mistakes that weaken an RFP
Asking for a fixed price on a scope that is not defined yet, listing hundreds of features with equal weight, and hiding the budget all lead to answers you cannot compare. If the scope is still open, ask vendors to price a discovery phase or a prototype first.
Check it for your case.
Common follow-up questions.
How long should an RFP be?
Long enough to answer the questions a vendor needs to estimate. A few clear pages beat a long list of generic requirements.
Should I share the budget?
Usually yes, as a range. It lets vendors propose what fits instead of guessing, and makes answers easier to compare.
How many vendors should I invite?
Enough for real choice, but few enough that you can read every answer properly and give fair feedback.
Related questions and guides.
- How do I choose a software agency?Question
- What goes in a statement of work?Question
- How do I plan a discovery phase?Question
- AI agent vs workflow automationComparison
- RAG vs fine-tuningComparison
- GlossaryEvery term, in plain words.
- Statement of workGlossary
- Acceptance criteriaGlossary
- Discovery phaseGlossary
