A useful software RFP explains the business result, gives every vendor the same facts and response format, and defines how proposals will be compared. It should not design the entire product before discovery; it should make assumptions, constraints, responsibilities, evidence and decision rules visible.
The checklist below is a vendor-ready structure for a custom software request for proposal. Complete the 12 numbered sections, attach the referenced materials, and issue one written clarification log to every bidder. You will receive proposals that are easier to evaluate—and you will expose uncertainty before it becomes an expensive change request.
An RFP is a decision system, not a feature wishlist
A feature wishlist says what screens or functions someone imagines. An RFP explains why change is needed, who is affected, what outcome counts as success, what is fixed, and where a vendor may recommend a better approach. That distinction matters: prescribing a solution too early can hide the real workflow, while vague objectives force each supplier to price a different interpretation.
If you are still deciding whether bespoke development is appropriate, first use this guide to planning and ordering custom software. Once the case is clear, the RFP becomes the controlled handoff from business need to vendor selection.
The GOV.UK Digital, Data and Technology Playbook targets public-sector sourcing, but its outcome focus, early market engagement, evaluation criteria and exit planning are useful to private buyers too. Apply them proportionately.
1. Business context and measurable outcomes
Start with a candid account of the organisation, the process being changed and why the project matters now. Include the systems involved, approximate operating scale, material constraints and decisions already made.
Then state three to five outcomes. An outcome is not “launch a portal”; it is a change you can observe, such as reducing manual re-entry, shortening a complete approval cycle, giving customers a reliable self-service path, or making a controlled process auditable. For every outcome, provide the current baseline if known, the desired direction or target, the measurement owner and the point at which it will be reviewed. Mark an unknown baseline as “to be measured during discovery” instead of inventing precision.
2. Users, roles and the current process
List each user group, including employees, customers, administrators, support staff, auditors and system accounts. Note its goal, frequency of use, approximate volume, access needs, device or connectivity constraints, and authority level. Identify the process owner and available subject-matter experts.
Map the current process from trigger to completion. Show handoffs, approvals, exceptions, duplicate entry, spreadsheets and offline steps—not only the ideal path. Add two or three representative scenarios. The GOV.UK guidance on writing user stories recommends capturing the actor, need and goal; that format is a useful way to express important journeys without dictating interface design.
3. Scope, priorities and explicit exclusions
Define the product boundary. Group capabilities as “required for first release,” “candidate for a later phase,” and “not in scope.” State whether the engagement covers discovery, design, development, hosting, migration, training, support and ongoing improvement. Name the required platforms.
Exclusions are as important as inclusions. If payroll, hardware procurement, content entry, a particular integration or round-the-clock support is excluded, say so. Also list decisions that remain open and who will make them. A vendor should not need to conceal contingency inside its price simply because the RFP leaves every boundary ambiguous.
4. Functional requirements as testable user needs
Organise functional requirements by journey or capability, not by pages. Give each one a stable identifier, priority, rationale and acceptance signal. Describe business rules, permissions, notifications, calculations, reporting and exception paths. Include sample inputs and outputs where they remove ambiguity.
Avoid making every statement mandatory. Use a consistent priority method and explain it. Invite vendors to identify dependencies or propose a simpler way to achieve the outcome. Separate facts from preferences: “finance must approve refunds above the configured threshold” is a rule; “use a three-step modal” is an implementation preference that may prevent a better design.
5. Quality, performance and operational service levels
Non-functional requirements determine whether software remains usable after the demo. Specify traffic and concurrency ranges, response-time objectives for critical actions, supported devices, availability windows, maintenance constraints, backup frequency, recovery objectives, observability, audit retention and growth assumptions.
Distinguish an SLO from an SLA. An SLO is the operating target the team designs and monitors; an SLA is a contractual commitment with defined measurement rules and remedies. State the measurement source, exclusions and reporting period for each one. Ask vendors to explain their monitoring, incident severity model, escalation path, status communication and post-incident review process rather than merely confirming “high availability.”
6. Data, migration and retention
Inventory source data by system, owner, format, volume, quality and sensitivity. Explain which records must move, which can remain archived, how duplicates should be handled and who approves mappings. Include anonymised samples when possible. State retention, deletion, export and legal-hold needs without asking a vendor to infer them.
Define migration evidence: reconciliation totals, rejected-record reports, sampling rules, rollback steps and business sign-off. For older systems, use the legacy software modernisation planning guide to decide whether replacement, staged migration or coexistence is realistic before making the supplier price an undefined “full migration.”
7. Integrations and external dependencies
For each integration, name the owner, purpose, direction of data flow, interface type, authentication method, environment availability, rate or volume expectations and known limitations. Attach current API documentation where you are allowed to share it. Note whether sandbox accounts exist and who coordinates with the third party.
Describe expected behaviour when a dependency is slow, unavailable or returns invalid data. Include retry, idempotency, timeout, reconciliation and manual recovery expectations where relevant. If an interface is undocumented or subject to another supplier’s schedule, flag that risk and request a priced discovery option rather than forcing bidders to pretend it is understood.
8. Security, privacy and accessibility
Summarise data classification, identity, privileged access, audit needs, encryption, secrets handling, environment separation, vulnerability management and incident notification. Ask who can access production data, how access is removed, and what evidence will be supplied before release. “The system must be secure” is not a threat model.
The NIST Secure Software Development Framework provides a common vocabulary for secure development practices and supplier conversations. For web application verification, select requirements appropriate to the risk from the OWASP Application Security Verification Standard and ask for test evidence—not an unsupported claim of compliance.
State privacy responsibilities, permitted processing, data location constraints and deletion workflows in language reviewed by the appropriate internal owner. For accessibility, name the target and verification method. WCAG 2.2 supplies testable, technology-neutral success criteria; specify the applicable conformance level, representative journeys, assistive-technology checks and remediation process.
9. Deliverables, intellectual property and handover
List stage deliverables: discovery findings, backlog, prototypes, architecture decisions, source code, automated tests, infrastructure configuration, deployment pipelines, data models, runbooks, training and support documentation. Define formats and where each asset must reside.
State ownership and licence expectations for bespoke code, reusable vendor components, open-source dependencies, designs, data and documentation. Require a dependency inventory and disclosure of recurring licences. Explain handover expectations, knowledge-transfer sessions, documentation review, credential transfer, exit assistance and the ability for another competent team to operate the product. Have qualified advisers review the final contractual terms; an RFP checklist is not legal advice.
10. Schedule, governance and change control
Provide business deadlines and their reasons, distinguishing fixed dates from assumptions. Identify stakeholder availability, blackout periods, dependency dates and approval lead times. Ask for a phased plan covering discovery, validation, delivery, migration, release and stabilisation.
Define governance roles: product owner, business decision-maker, technical authority, security and privacy reviewers, vendor delivery lead and escalation contacts. State meeting and reporting expectations, but focus governance on decisions and evidence. Require a change-control method that records the request, reason, impact on outcomes, cost, schedule and risk, plus the person authorised to approve it. Agile delivery still needs commercial control; it simply handles learning transparently instead of pretending requirements will never change.
11. Acceptance, testing and evidence
Describe how work becomes accepted and payable. Criteria should be observable, linked to a requirement and supported by evidence. Include functional, integration, accessibility, security, performance, migration and user-acceptance checks where relevant. Name the environments, data responsibility, defect rules, retest process and sign-off owner.
Do not write “zero bugs” or “client satisfaction” as acceptance criteria. A stronger example is: “Given an authorised finance user and a valid refund above the configured threshold, the request is routed to the required approver, the decision is timestamped in the audit log, and an unauthorised user cannot approve it.” Ask the vendor to provide a requirements-to-evidence traceability view so omissions can be found before launch.
12. Pricing assumptions and a standard vendor response
Give bidders one response template. Require an executive summary, proposed approach, assumptions, exclusions, team and named roles, relevant case studies, delivery plan, risk register, architecture outline, security and accessibility approach, support model, dependencies, references and a completed compliance table. Set a page limit where useful, a question deadline and one channel for shared clarifications.
Request pricing by phase and deliverable, with rate cards and the commercial model clearly identified. Separate one-time build, migration and launch costs from recurring hosting, licences, monitoring, support, third-party services and anticipated maintenance. Ask for optional items and the validity period of the offer. The custom software cost and TCO guide helps build a comparable cost model without relying on arbitrary market averages.
Require every assumption to be priced or connected to a stated impact. A low total based on client-supplied design, clean data and no support is not comparable with a proposal that includes those activities. Your evaluation should normalise scope before comparing totals.
Use a weighted evaluation matrix before opening proposals
Publish the criteria and requested evidence in the RFP; finalise internal weights before bids arrive. A practical starting matrix might be:
| Criterion | Example weight | Evidence to review | |---|---:|---| | Understanding of outcomes and users | 15% | Restated problem, assumptions, discovery plan | | Delivery approach and governance | 15% | Phases, decision gates, dependency handling | | Technical, security and accessibility quality | 20% | Architecture, verification plan, relevant evidence | | Team capability and continuity | 15% | Named roles, allocation, comparable work | | Operations and handover | 10% | SLO model, runbooks, exit and knowledge transfer | | Total cost and commercial clarity | 20% | Normalised TCO, rates, exclusions, options | | Proposal quality and risk transparency | 5% | Complete response, explicit risks and mitigations |
Adjust weights to your risk profile and define what scores of 1, 3 and 5 mean for each criterion. Have at least two evaluators score independently, record evidence, reconcile material differences and check references. A polished presentation should not outweigh missing evidence or concealed assumptions.
A practical mini-example
Imagine a distributor replacing emailed warranty-claim spreadsheets. A weak RFP asks for “a modern portal with dashboards.” A strong one seeks fewer incomplete submissions and traceable decisions, then supplies user groups, sample claim states, approval rules, data quality, ERP ownership and expected volume.
The first release includes claim submission, document validation, status tracking, role-based review and accounting export; predictive fraud scoring is later-phase. One test proves that resellers cannot see each other’s claims; another reconciles migrated open claims by status and value. Vendors price discovery, release, migration rehearsal, cutover and stabilisation separately. The matrix emphasises migration evidence and integration resilience.
This example is specific enough to compare approaches but still leaves room for a supplier to recommend workflow and architecture improvements.
Pre-send RFP checklist
Before release, confirm that:
- a cross-functional group has reviewed the outcomes, scope and priorities;
- every mandatory requirement has an owner and a reason;
- sample data is anonymised and shared through an approved channel;
- unknowns, dependencies and bidder assumptions are visible;
- acceptance criteria are testable and linked to evidence;
- all vendors receive the same dates, attachments and clarification answers;
- the response template, scoring weights and decision process are fixed;
- security, privacy, accessibility, operations and exit are covered;
- price instructions separate implementation from recurring TCO; and
- the final RFP is internally consistent, accessible and version-controlled.
Common mistakes that make proposals incomparable
The most damaging mistake is mixing outcomes, mandatory requirements and optional ideas in one unprioritised list. Others include hiding the incumbent system, fixing a price for unresolved migration, demanding a technology without a constraint, omitting sample data, postponing security and accessibility, and evaluating only company credentials.
Avoid a winner-takes-all spreadsheet in which small price differences overpower delivery risk. Do not ask for unpaid speculative design that you cannot evaluate consistently. Do not keep clarification answers private. Finally, do not treat contract award as the end of selection: named-team availability, discovery findings and an early delivery checkpoint should validate that the proposal can become a working relationship.
Turn the checklist into a procurement-ready brief
A strong RFP makes uncertainty discussable. It gives capable vendors enough context to challenge assumptions, makes trade-offs visible and creates a defensible link from business outcome to acceptance evidence. Complete the 12 sections, remove requirements you cannot justify, test the response template with an internal reviewer, and issue one controlled version to every bidder.
The EasySaz custom software development service can help translate a business process into a discovery plan, delivery scope and evidence-based proposal. To review your draft RFP or prepare a vendor-ready brief, contact the EasySaz team.