Procurement for public organisations: how to buy a website properly
How a public body can specify, evaluate and contract a website or application within procurement rules and end up with something it owns and can maintain.
The short answer
Public organisations buy websites and applications through procurement rules: thresholds decide the procedure, the procedure sets the steps, and evaluation criteria decide the winner. The rules are the frame; the outcome is decided by what goes inside it. A well-specified procurement names the non-negotiables as pass-or-fail requirements: accessibility to the referenced standard, ownership of code and data, open standards, documentation, exit terms, a security baseline, hosting in the organisation’s accounts. It evaluates on evidence rather than promises: a working sample tested for accessibility and speed, a hand-over pack from a previous client, named people, a maintenance plan with numbers. And it weights quality and five-year cost over initial price, because a bid is only lower on the lines it contains: hosting, maintenance, accessibility work and the hand-over arrive during the contract whether or not they were quoted. Check the specific rules for your organisation with your procurement and legal teams; what follows is what to put inside them.
Requirements: pass-or-fail versus evaluated
| Pass-or-fail (non-negotiable) | Evaluated (weighted criteria) |
|---|---|
| Accessibility to the referenced standard, audited at acceptance | Quality of the proposed approach and design |
| Code in the organisation’s repository; data in open formats with export on demand | Evidence from previous work: samples, tests, references |
| Hosting and accounts in the organisation’s name | Maintenance plan: scope, cadence, response, monthly cost |
| Documentation to a defined standard; hand-over defined | Named team and their experience |
| Exit terms with cooperation | Five-year total cost, not build price |
| Security baseline and privacy by design with an assessment | Approach to content, migration and training |
| Open standards for data exchange and interfaces | Sustainability and performance practices |
Running it well
- Write the requirements around outcomes and non-negotiables, with pass-or-fail items separated from weighted ones.
- Require evidence with each bid: a sample to test, a hand-over pack, a maintenance report, named people.
- Test the samples yourselves: keyboard, screen reader, mobile speed, structured data.
- Weight five-year total cost, including maintenance, over build price.
- Procure maintenance in the same process with a defined scope, term and exit.
- Put ownership, documentation and exit in the contract as deliverables with acceptance criteria.
- Verify at acceptance: accessibility audit, repository transfer, documentation, accounts in your name.
After award
The contract includes what the requirements demanded: accessibility audited at acceptance, repository in the organisation’s account, documentation to the standard, accounts in the organisation’s name, maintenance with its report, exit with hand-over. The organisation verifies each at the defined moment rather than trusting the bid. A yearly check that a second supplier could take over from the documentation keeps the exit real.
What this means for you
Use the procurement rules as the frame and put the right things inside it: non-negotiables as pass-or-fail, outcomes as weighted criteria, evidence tested during evaluation, five-year cost over build price, and maintenance procured alongside. Verify ownership, accessibility and documentation at acceptance. A public website procured this way is one the organisation owns, can maintain and can hand to the next supplier, which is what the rules were written to achieve.
Frequently asked questions
How do we avoid buying the cheapest bid that turns out to be the worst?
By setting evaluation criteria that weight quality, ownership, accessibility, maintenance and five-year cost, and by requiring evidence for each: a live sample tested for accessibility and speed, a hand-over pack from a previous client, a maintenance plan with response times and monthly cost. Price alone as the criterion produces the outcome everyone complains about; the criteria are within your control.
What must the requirements include?
The non-negotiables as pass-or-fail: accessibility to the referenced standard with an audit at acceptance, code in the organisation's repository, data in open formats with export on demand, hosting in the organisation's accounts, documentation to a defined standard, exit terms with hand-over, a security baseline, privacy by design. Then the functional outcomes as evaluated criteria. Check the specific legal requirements for your organisation with your procurement and legal teams.
How do we handle the maintenance after the build?
Procure it as part of the same process, with a defined scope, cadence, response times and monthly cost, for a defined term with an exit. A website without maintenance decays and becomes non-compliant; procuring the build without the maintenance leaves the organisation with an asset nobody is contracted to keep working.
Sources
- European Commission: Public procurement (accessed 2026-09-12)