Software for municipalities: procurement, accessibility and open standards
What changes when the client is a public organisation: how it buys, what it must comply with, and what it should insist on owning.
The short answer
Building software for a municipality or another public organisation is the same craft with stricter discipline around three things. Procurement: the organisation buys through formal rules, with documented requirements, evaluation and contracts. Compliance: accessibility and privacy are legal obligations with audits, applying to every screen, document and process the software touches, for citizens and for staff. Continuity: the organisation outlives every supplier and every administration, so open standards for data and interfaces, code ownership, documentation and exit terms are not preferences but protections. The best public software is deliberately boring: standard, accessible, owned, and built from the first day to be handed to the next supplier.
What changes
| Area | In a company | In a public organisation |
|---|---|---|
| Buying | A proposal and a decision | Procurement procedure: requirements, thresholds, evaluation criteria, transparency |
| Accessibility | Good practice, sometimes required | Legal requirement with monitoring and audits; applies to websites, apps and internal tools |
| Privacy | Legal requirement | Legal requirement with higher scrutiny; data protection assessments common; citizens’ data |
| Ownership | Strongly advisable | Expected: code, data, accounts; open formats for export; documented exit |
| Standards | Preferred | Open standards for data exchange and interfaces expected or mandated |
| Continuity | Business risk | Institutional: the system must survive supplier and political change |
| Documentation | For the next developer | For the next supplier, the auditor and the archive |
Building to the standard from the start
- Accessibility in the design system: components that are keyboard operable, labelled, high contrast and screen reader tested before any screen is built with them.
- Documents the system produces are accessible too: exports, letters, PDFs.
- Data in open formats with export available at any time, and interfaces documented openly.
- Privacy by design: minimisation, retention, access control and audit logs, with the assessment done before build.
- Code in the organisation’s repository, infrastructure in its accounts, everything documented to the stranger test.
- Exit terms in the contract describing hand-over, and a yearly rehearsal that a second party could take over.
What the organisation should insist on
An accessibility statement backed by testing, not a badge. Data exportable in open formats on request. The repository in its own account with the supplier as collaborator. Infrastructure in its own name. Documentation that a second supplier could use. Exit terms with a hand-over description. Regular demonstration that all of that is true, not only at the start. These make supplier change a procurement exercise rather than a crisis, which is the situation the rules exist to protect.
What this means for you
If you are a public organisation, build accessibility, open standards and ownership into the requirements and the contract, and verify them throughout rather than at launch. If you are a supplier, build to those standards from the first component and expect to be judged on what you leave behind. Public software that is boring in these ways is the software that still works, still complies and is still owned when the next administration arrives.
Frequently asked questions
How is building for a municipality different from building for a company?
Three ways: the buying process is formal and documented, accessibility and privacy requirements are legal obligations with audits, and continuity matters more, because the organisation outlives every supplier and every administration. The technology is the same; the discipline around ownership, standards and documentation is stricter.
What does accessibility mean for internal software, not just websites?
The same standard applies to applications used by staff and by citizens: keyboard operability, screen reader support, contrast, labelled forms, announced errors, accessible documents produced by the system. Internal tools are frequently the least accessible and the most used. Build them to the standard from the start; retrofitting an application is far harder than retrofitting a page.
What should a public organisation insist on owning?
The code in its own repository, the data in its own systems in exportable open formats, the accounts and infrastructure in its own name, documentation that passes the stranger test, and exit terms that describe hand-over. A public organisation that owns those can change supplier without losing the system, which is the situation procurement rules are designed to make possible.
Sources
- European Commission: Web Accessibility Directive (accessed 2026-09-12)