UK Public Sector Software Projects: From Procurement Requirements to a Deliverable Product
How UK public sector software is bought and delivered: Procurement Act 2023, most advantageous tender, Cyber Essentials, Service Standard and accessibility.
How are UK public sector software projects bought and delivered?
Public bodies in England, Wales and Northern Ireland buy under the Procurement Act 2023 (since 24 February 2025), awarding contracts to the most advantageous tender against published criteria rather than the lowest price. Many buy digital services through frameworks. Central government and NHS contracts with certain characteristics require Cyber Essentials, websites and apps must meet WCAG 2.2 AA with an accessibility statement, and central government services are expected to meet the 14-point Service Standard. Delivery that works turns the procurement requirements into user needs and outcomes through discovery, alpha, beta and live phases, rather than building a fixed specification blindly.
This guide is for suppliers bidding for public sector software work and for public sector product owners turning a requirement into a deliverable product. It is general information as at October 2026, not legal or procurement advice. Scotland has a separate regime.
Key takeaways
- Know which regime applies: Procurement Act 2023, or Scottish rules.
- Evaluation is on the most advantageous tender, not just price.
- Register on the Central Digital Platform to bid under the Act.
- Check Cyber Essentials, accessibility and security requirements early.
- Plan delivery in phases, starting with discovery.
- Write bids around outcomes and evidence, not feature lists.
What the Procurement Act 2023 changed for software suppliers
| Area | What it means in practice |
|---|---|
| Most advantageous tender | Award against published criteria and weightings; quality and social value can outweigh price (guidance on assessing tenders) |
| Central Digital Platform | Suppliers register core information once and reuse it across bids |
| Transparency notices | More notices across the lifecycle, including pipeline, award and contract performance information |
| Exclusions and debarment | Grounds for excluding suppliers, including a central debarment list |
| Procedures | Open procedure and a flexible competitive procedure that suits iterative digital work |
| Scope | England, Wales and Northern Ireland; devolved Scottish authorities follow Scottish regulations |
Common requirements to check before bidding
- Cyber Essentials: PPN 014 applies to central government departments, agencies, NDPBs and NHS bodies for contracts with certain characteristics; certification must be renewed annually.
- Accessibility: WCAG 2.2 AA and an accessibility statement under the public sector accessibility regulations (GOV.UK).
- Service Standard and Technology Code of Practice: central government services are expected to meet them; see the Service Standard for product teams and the Technology Code of Practice.
- Data protection and security: UK GDPR processor terms, security clearance for some roles, data location requirements.
- Open source and ownership: whether new code must be open and who owns IP.
- Social value: evidence for any social value criteria.
How buyers evaluate software suppliers beyond the lowest bid
Private and public buyers can use the same structure: publish criteria, weight them, and score evidence rather than claims.
| Criterion | What good evidence looks like |
|---|---|
| Understanding of users and problem | A clear view of users and risks, and how discovery will test assumptions |
| Delivery approach | Phased plan, team roles, governance, how change is managed |
| Technical approach | Architecture, integration, security, accessibility, hosting and exit |
| Relevant experience | Comparable work that evaluators can verify |
| Team | Named roles, seniority and continuity |
| Social value | Specific, measurable commitments |
| Price | Transparent rates and assumptions; whole-life cost |
Turning procurement requirements into a deliverable product
Tender documents often mix genuine needs with solutions someone assumed. The safest route is to treat requirements as hypotheses and test them early, within the contract's scope.
| Phase | Purpose | Typical outputs |
|---|---|---|
| Discovery | Understand users, problem, constraints and policy | User needs, journey maps, risks, recommendation on whether to proceed |
| Alpha | Test riskiest assumptions with prototypes | Tested prototypes, technical spikes, plan for beta |
| Beta | Build a working service with real users | Private then public beta, accessibility audit, security testing, performance data |
| Live | Run and improve the service | Support model, continuous improvement, published performance where required |
Pro tip
Agree in the contract how scope changes are handled when discovery or alpha shows a requirement is wrong. Fixed specifications with no change route are a common cause of failed public sector projects.
Hypothetical example: a council licensing service
This example is hypothetical. A district council tenders for a replacement online licensing service. The winning supplier's bid scores well on quality because it proposes a four-week discovery with licence applicants and officers, a prototype tested with users with access needs, an integration plan for the council's case management system, and a clear exit plan. Discovery shows that most failed applications come from unclear evidence requirements, so the alpha focuses on guidance and document upload rather than the payment features the specification emphasised.
Common mistakes
- Treating the specification as fixed when discovery shows otherwise.
- Bidding on price and features instead of evidence and outcomes.
- Leaving accessibility and security to the end.
- Missing Cyber Essentials or registration requirements.
- Ignoring whether the Procurement Act or Scottish rules apply.
Sources
Procurement Act 2023; Cabinet Office: Procurement Act 2023 guidance; Guidance: assessing competitive tenders; PPN 014: Cyber Essentials scheme; Accessibility requirements for public sector websites and apps; Service Manual: agile delivery.
Accessed 10 October 2026. Procurement rules differ in Scotland. Nothing here is legal or procurement advice.
Conclusion
Public sector software is bought on the most advantageous tender and delivered best in phases that test requirements with users. Suppliers should check the regime, registration, Cyber Essentials, accessibility and Service Standard expectations before bidding, then write evidence-led bids. Buyers should publish clear criteria and leave room for discovery to change the plan.
Planning a public sector digital service?
ZSpace Labs is a remote-first technology studio that works with clients globally on web applications and service and interface design. We have no UK office and do not claim places on public sector frameworks. If it would help to talk through discovery or delivery planning, we are happy to.
Common questions.
In England, Wales and Northern Ireland, the Procurement Act 2023 has applied to procurements started on or after 24 February 2025. Devolved Scottish authorities follow Scottish regulations, such as the Public Contracts (Scotland) Regulations 2015. Contracts awarded under earlier rules continue under those rules.