Government & Public Sector
Public services that work for everyone who needs them.
e-Governance platforms, citizen services, and case management built to accessibility and transparency standards — and to budgets that have to be publicly defended.
14
Public bodies served
3M+
Citizens served
AA
WCAG conformance
52%
Fewer counter visits
The pressure
What government teams are actually dealing with
Services that assume a confident digital user
Forms designed for the median applicant, which fail the people with the most complex circumstances and greatest need.
Departmental systems that cannot talk
Citizens asked to supply the same information repeatedly because two departments hold separate, unlinked records.
Procurement that outlasts the requirement
Specifications written years before delivery, locking in an approach that no longer matches the policy it was meant to serve.
Legacy systems with no exit plan
Critical services running on platforms with a shrinking support market and no documented path off them.
What we build
What we build for public bodies
Built to be inspected — accessible, documented, and handed over with the source and the reasoning behind it.
Citizen service portals
Application, tracking, and correspondence journeys tested with users who have the hardest cases, not the easiest ones.
- Assisted digital paths
- Plain-language content
- Progress transparency
Case management
Caseworker tools that reduce handling time while keeping the decision record complete enough for appeal and audit.
- Decision audit trail
- Workload balancing
- Appeal support
Digital identity
Verification and authentication proportionate to the service, with alternative routes for citizens who cannot use the primary one.
- Proportionate assurance
- Alternative routes
- Consent management
Interdepartmental integration
Data sharing between agencies under clear legal basis, with logging and minimisation designed in from the start.
- Purpose-bound sharing
- Data minimisation
- Access logging
Open data & transparency
Published datasets and service performance data with documented provenance and a stable, versioned interface.
- Versioned open APIs
- Documented provenance
- Performance publishing
Legacy replacement
Incremental migration off unsupported platforms with continuity of service throughout and no single high-risk cutover.
- Incremental cutover
- Service continuity
- Documented exit path
Compliance
The regulatory surface we build against
Controls are designed into the architecture and evidenced in the pipeline, so an audit is a report rather than a project.
Outcomes
What these engagements produced
Representative results from engagements in this sector.
- 01
Municipal authority
Counter visits down by half
Redesigned the six highest-volume services around the applicants who previously had to attend in person, with assisted digital routes retained.
- 02
National agency
Processing time reduced from 21 days to 6
Case management automation removed three manual handoffs while strengthening the decision record used at appeal.
- 03
Regional department
Off an unsupported platform without downtime
Incremental migration of a citizen-facing service across eleven months, with the legacy system decommissioned only after parallel running.
How we deliver here
Three things that make public sector delivery different
Universal service
The hardest user is the one you design for
A commercial product can afford to lose the user on an old device with a poor connection and a screen reader. A public service cannot — that user often has no alternative and the greatest need.
- WCAG 2.2 AA verified in CI and by assisted-technology testing
- Core journeys working before JavaScript loads
- Tested on low-bandwidth connections and older devices
- Assisted-digital and offline routes designed, not assumed
Transparency
Built to be published and scrutinised
Public work gets read by people who did not commission it — auditors, journalists, opposition members. We assume the design decisions, the code and the findings will be public, which is a healthy constraint.
- Findings written to be publishable without redaction
- Decision records that explain the trade-off, not just the choice
- Open standards and open formats by default
- Spend and delivery reporting suitable for public scrutiny
Sovereignty
Where the data runs is a design input
Hosting location, sub-processor chain and operator nationality are frequently constrained before any technical requirement is written. Discovering that in month six is expensive; we establish it in week one.
- Residency and sovereignty constraints confirmed up front
- Sub-processor chain documented and approved
- Exit and data-portability plan required from day one
- Procurement-compatible architecture, not vendor-locked
Delivery constraints
What each public sector constraint changes in practice
These are the ones that reshape the architecture rather than adding a paragraph to the contract.
| Constraint | Set by | What it changes | When to resolve it |
|---|---|---|---|
| AccessibilityNon-negotiable | Statutory duty | Every screen, every journey, the whole front end | Before the design system is agreed |
| Data residency | Sovereignty policy | Hosting region, provider, sub-processors | Week one, before architecture |
| Open standards | Procurement policy | Interfaces, formats, exit path | At the integration design stage |
| Records retention | Statute and archive rules | Data lifecycle and deletion design | Before the data model is fixed |
| Procurement framework | Commercial policy | Contract shape, phase length, exit terms | Before the statement of work |
Accessibility
Non-negotiable- Set by
- Statutory duty
- What it changes
- Every screen, every journey, the whole front end
- When to resolve it
- Before the design system is agreed
Data residency
- Set by
- Sovereignty policy
- What it changes
- Hosting region, provider, sub-processors
- When to resolve it
- Week one, before architecture
Open standards
- Set by
- Procurement policy
- What it changes
- Interfaces, formats, exit path
- When to resolve it
- At the integration design stage
Records retention
- Set by
- Statute and archive rules
- What it changes
- Data lifecycle and deletion design
- When to resolve it
- Before the data model is fixed
Procurement framework
- Set by
- Commercial policy
- What it changes
- Contract shape, phase length, exit terms
- When to resolve it
- Before the statement of work
Questions
What public sector clients ask first
Usually about accessibility evidence and about lock-in.
Standards and procurement
How do you evidence accessibility conformance?
Automated checks run in CI on every pull request, supplemented by manual testing with screen readers and keyboard-only navigation, and an audit against WCAG 2.2 AA before launch. Automated tooling alone catches perhaps a third of real issues, so we do not present it as sufficient — the manual testing is where the useful findings come from.
Will we be locked into your team?
No, and the procurement framework usually forbids it anyway. Code sits in your repository under an open licence where policy requires it, interfaces use open standards, and an exit and portability plan is a required deliverable rather than a closing conversation. We would rather compete for the next phase than be retained by inertia.
Can you work within our existing framework agreement?
Generally yes — we scope work to fit the phase structure and reporting the framework expects rather than asking for a bespoke contract shape. Where a framework's phase length genuinely conflicts with sensible delivery we will say so early and propose an alternative you can take to your commercial team.
Working in a different sector?
The engineering practice is the same across every vertical we serve. Browse the full list, or tell us what you are dealing with.
All industriesStart with a service assessment.
An accessibility, usability, and architecture review of one service — with findings you can publish.