A software development RFP, or request for proposal, gives prospective suppliers enough shared information to explain how they would solve a problem and what their proposal includes. Its value is comparability. A long document can still produce incompatible bids if the important workflow, data and operating assumptions remain unclear.
Use the original template below as a starting point for a custom-development brief. It is a working document for project discussion, not a legal agreement or a prescribed public-procurement process. Adjust it to the organisation and the evidence available.
Resolve the problem before prescribing every feature
Describe the people affected, what they need to achieve and the current difficulty. Include existing evidence and its limits. “Dispatchers reconcile requests in three spreadsheets” is more informative than “build a powerful enterprise dashboard”.
The GOV.UK discovery guidance starts from understanding users, the problem and constraints before committing to a service. For a commercial project, use that principle to identify what suppliers can estimate and what still needs investigation.
Use this software development RFP structure
| Section | Copyable prompt | Evidence to attach |
|---|---|---|
| Business outcome | We need [users] to complete [task] so that [observable outcome]. | Current process and known measures |
| First-release scope | Include [workflows and roles]; exclude [deferred capabilities]. | Prioritised task and role list |
| Data and systems | The authoritative sources are [systems]; access currently available is [detail]. | Safe sample records and API references |
| Constraints | We must work within [business, technical and review constraints]. | Known dependencies and named owners |
| Acceptance | We will assess [representative scenarios] using [checks]. | Successful and unsuccessful task examples |
| Operations | After release, [team] will own [support and platform duties]. | Existing support and recovery arrangements |
| Supplier response | Please state approach, evidence, assumptions, exclusions and estimate basis. | Common response headings |
Keep placeholders visibly unresolved until the responsible person fills them. If a fact is unknown, say so. A supplier should not have to discover that an apparently confirmed data source is actually a spreadsheet no one has reviewed.
Provide a workflow that exposes the hard parts
For a hypothetical dispatch application, describe how a customer request becomes an assigned job and how staff handle missing information. Identify roles that may view, assign, approve or cancel it. Include what happens when an external scheduling service is unavailable.
Attach a small controlled example with record relationships and expected outcomes. Avoid exposing live personal or commercially sensitive data in a general invitation. Agree an appropriate access process for detailed material rather than placing unrestricted production access in the RFP.
Distinguish requirements, options and unknowns
Mark necessary outcomes separately from preferred approaches. “Authorised staff can export approved jobs” is a requirement. “Use a particular reporting library” is a proposed implementation constraint that needs a reason if it is mandatory.
Ask suppliers to explain how unknowns affect the estimate. For example, migration may depend on the quality of old identifiers, and integration may depend on access to a sandbox. Request a discovery option or a clear allowance rather than encouraging each bidder to assume a different easy case.
Request evidence of delivery and operation
Ask how representative changes are reviewed, tested, released and recovered. Request examples the supplier is permitted to share, and distinguish a demonstrated practice from an unsupported marketing statement. Do not require them to invent a relevant client case where disclosure is unavailable.
Specify access and handover expectations for repositories, environments, documentation and operational knowledge. Have commercial or legal reviewers assess ownership and contractual terms. The RFP should expose questions for agreement, not imply that a template settles rights.
Require a consistent cost response
Give bidders the same headings: initial work, optional work, recurring external charges, support, client responsibilities, assumptions and exclusions. Ask whether the estimate is fixed, time-based, capped or conditional on discovery, and what changes it.
Separate implementation effort from elapsed delivery time. Identify decisions, data and access required from your own team. A shorter schedule may depend on client availability or omitted migration work rather than a better delivery method.
Choose evaluation criteria before receiving bids
As an illustrative rubric, weight workflow understanding at 25%, delivery and testing evidence at 20%, operational ownership at 20%, price and estimate clarity at 20%, and collaboration/dependency handling at 15%. These suggested weights total 100%; they are not a universal buying rule.
Keep essential conditions as separate gates. For each scored item, record the evidence and unanswered questions. A low price should not cancel a failure to support a necessary access boundary or an unresolved ownership condition.
Clarify gaps using the same process
Keep a question register containing the question, answer, effect on scope and affected proposal sections. Where appropriate to the buying process, share material clarifications consistently so suppliers still price the same work. Record changes rather than relying on separate undocumented conversations.
Shortlist against the requirements and ask the remaining suppliers to walk through the difficult scenario. If uncertainty remains fundamental, a limited discovery engagement may produce a better next decision than requesting a more confident fixed price from insufficient information.
Turn the selected proposal into a delivery brief
Before work begins, reconcile the RFP, supplier response and clarifications into agreed scope, acceptance and responsibilities. Resolve contradictions explicitly. Plan how proposed changes will be considered and who can approve them.
The software discovery guide explains investigation before implementation. Bring the completed brief to a custom software development discussion so the commercial proposal can respond to a defined problem rather than an interchangeable feature wish list.
