Why Software Development RFPs Are Different
An RFP for software development requires a fundamentally different approach from buying off-the-shelf products. You're procuring a creative, iterative process with inherent uncertainty — not a fixed commodity. The best software development RFPs balance enough specificity to get comparable proposals with enough flexibility for vendors to propose innovative approaches.
The GOV.UK Service Manual provides extensive guidance on procuring digital services, and the Technology Code of Practice sets standards for technology procurement across government.
Key Sections of a Software Development RFP
Business Context & Objectives
Don't just describe what you want built — explain why:
- What business problem are you solving?
- Who are the users and what are their needs?
- What does success look like? (measurable outcomes)
- What constraints exist? (budget, timeline, technology, regulatory)
- What's the strategic context? (digital transformation, legacy replacement, new capability)
Functional Requirements
Describe desired capabilities, not technical specifications:
- User stories — "As a [user], I need to [action] so that [outcome]"
- Prioritisation — MoSCoW (Must, Should, Could, Won't) as per GOV.UK agile delivery guidance
- User journeys — Key workflows the system must support
- Acceptance criteria — How you'll determine if a requirement is met
- Out of scope — Clearly state what's NOT included
Technical Requirements
Set constraints without being overly prescriptive:
- Technology preferences — If you have constraints (e.g., must integrate with .NET stack)
- Hosting — Cloud (which provider?), on-premise, hybrid, GOV.UK Cloud Guide
- Security — Cyber Essentials, ISO 27001, penetration testing requirements
- Accessibility — WCAG 2.1 AA minimum (mandatory for public sector per accessibility regulations)
- Performance — Response times, concurrent users, data volumes
- Integration — APIs, data formats, existing systems to connect with
- Data — UK GDPR compliance, data residency, retention policies
Development Methodology
State your expectations or ask vendors to propose:
- Agile delivery — Sprints, ceremonies, Definition of Done
- User research — How and when user testing will be conducted
- Iterative development — MVP approach, phased delivery, continuous deployment
- Quality assurance — Testing strategy (unit, integration, UAT, accessibility, security)
- Source control — Repository management, branching strategy, code review process
- DevOps — CI/CD, infrastructure as code, monitoring and alerting
Team Requirements
Define the team you need:
- Key roles — Technical lead, developers, UX designer, QA, product owner support
- Seniority — Expected experience levels for each role
- Availability — Full-time vs part-time, on-site vs remote
- Continuity — Maximum staff turnover expectations
- Knowledge transfer — How capability will be transferred to your team
Intellectual Property & Ownership
Critical for software development:
- Code ownership — Who owns the source code? (For public sector, GOV.UK guidance recommends open source where possible)
- Licencing — What licences apply to third-party components?
- Documentation — Technical docs, architecture decisions, operational runbooks
- Handover — Requirements for transferring to a different supplier if needed
- Open source — Expectations around contributing back to the community
Pricing Model
Software development pricing options:
- Fixed price — Suitable for well-defined requirements with limited change
- Time & materials — Suitable for exploratory or evolving requirements
- Capped T&M — Flexibility with budget certainty
- Outcome-based — Payment linked to defined measurable outcomes
- Day rates — For staff augmentation or advisory engagements
Evaluation Criteria
Typical weightings for software development RFPs:
| Criterion | Typical Weighting | |-----------|------------------| | Technical approach & methodology | 25-35% | | Team capability & experience | 20-25% | | Understanding of requirements | 15-20% | | Relevant case studies | 10-15% | | Price | 20-30% | | Social value | 5-15% |
Software Development RFP Best Practices
1. Focus on Outcomes, Not Outputs
Bad: "Build a web application with 47 specific features" Good: "Enable 500 users to process applications 50% faster while maintaining compliance with [regulations]"
2. Allow for Discovery
The best software projects start with a discovery phase. Consider structuring your RFP to allow:
- Initial discovery sprint (2-4 weeks) to validate assumptions
- Prototype/MVP phase to test core hypotheses
- Iterative build phase informed by user research
This aligns with GOV.UK service design phases: Discovery → Alpha → Beta → Live.
3. Be Realistic About Timeline
Software development is unpredictable. Build in:
- Discovery time before committing to scope
- Contingency for unknowns (10-20% is standard)
- UAT and training time before go-live
- Hypercare period after launch
4. Specify Your Involvement
The buyer's participation significantly affects project success:
- Product owner availability (how many days per week?)
- Decision-making authority and escalation paths
- User research participant availability
- UAT resource commitment
- Stakeholder engagement approach
5. Include Non-Functional Requirements
These often determine project success more than features:
- Performance under load
- Security and penetration testing requirements
- Accessibility audit expectations
- Browser and device support matrix
- Disaster recovery and business continuity
- Monitoring, logging, and alerting requirements
Common Mistakes in Software Development RFPs
- Over-specifying the solution — Describing screens and fields instead of user needs
- Underestimating complexity — Not allowing for integration, migration, or organisational change
- Ignoring non-functionals — Security, performance, and accessibility as afterthoughts
- Unrealistic timelines — Not accounting for discovery, testing, and change management
- Unclear IP provisions — Ambiguity about code ownership creates future problems
- Waterfall in disguise — Asking for Agile but expecting fixed scope, time, and budget simultaneously
Using rfp.quest for Software Development RFPs
Whether you're issuing a software development RFP or responding to one:
For buyers:
- RFP templates aligned with GOV.UK service standards
- Requirement structuring tools (user stories, acceptance criteria)
- Evaluation framework builder for technology procurement
For suppliers:
- AI-assisted response drafting for technical proposals
- Case study matching for relevant software development experience
- Compliance checking against RFP requirements
- Team capability presentation templates
See our RFP for software development template for a downloadable starting point.
Frequently Asked Questions
Should I specify the technology stack? Only if you have genuine constraints (e.g., must integrate with existing systems). Otherwise, let vendors propose their preferred stack and evaluate their reasoning.
How do I evaluate Agile proposals against each other? Focus on: team quality, understanding of your problem, approach to risk, communication practices, and relevant experience. Don't compare fixed feature lists — compare approaches and evidence.
What about vendor lock-in? Mitigate through: open source code, standard APIs, documented architecture, and knowledge transfer provisions. The Technology Code of Practice provides guidance.
Should I ask for a prototype or proof of concept? Consider a paid "sprint zero" or technical assessment as part of your evaluation process, rather than asking for free work. This gives you better insight while respecting vendors' investment.
Create your software development RFP → with rfp.quest or download our free template.