Public services are held to standards that most software is not, and are assessed by people who will look. Accessibility, security, auditability and the ability to evidence a decision are not features to be added at the end; they shape how a service is built from the first sprint.
That is the same discipline our regulated work already runs on. ECS Group Command carries role-based access across nine service areas, audit trails on every record and compliance evidence assembled as the work happens rather than reconstructed afterwards.
Insights
Accessibility is a build practice, not an audit
An audit at the end of a project finds real problems at the most expensive possible moment. Almost all of them were avoidable weeks earlier.
Read the articleBuilding for a handover you have not scheduled yet
Every supplier relationship ends. Whether that is routine or painful is decided by choices made in the first month, not the last one.
Read the articleAn audit trail that answers questions nobody has asked yet
Most logging records that something happened. What gets asked later is why, by whom, and what the system knew at the time.
Read the article
How we support changemakers in the public sector
Set up and run teams
We work inside your teams rather than at arm's length from them, and we leave the knowledge behind. Small senior groups embedded alongside your people, not large ones managed from a distance.
Launch new products
We build to production standards from the first sprint: tested, observable, documented, accessible. In public services the thing that delays a launch is rarely the feature, it is being unable to evidence how it behaves.
Discover new propositions and customer experiences
User-centred design means research with the people who will actually use the service, including the ones who find it hardest. We design for the edge of the distribution, not the middle.
How we strengthen your team
Accessibility as part of the build
Built to WCAG standards as work proceeds rather than audited at the end, because retrofitting accessibility is always more expensive and usually worse.
Evidence, not assertion
Role-based access, audit logging and clear documentation as standard, so how a service works can be demonstrated rather than described. Built this way already for safety-critical rail work held to ORR and HSE expectations.
Built to be handed over
Contract-first APIs, infrastructure as code and documentation written for the team who will run it. Nothing about the way we build assumes we stay.
Assured against the standards you are assessed on
WCAG conformance tested as the work proceeds — automated checks in the pipeline, keyboard operation on every component as it is built, and assistive technology used in development rather than only at audit. Independent assessment then confirms rather than discovers.
No lock-in by construction
Source, infrastructure definitions and deployment pipeline in a repository you own from the first sprint, not delivered at closure. Open standards, documented data export that has actually been tested, and decision records kept with the code so the next team inherits the reasoning.
Service performance you can publish
Completion rates, drop-off points, failure demand and digital take-up captured as the service runs, in a form that can be reported publicly. Transparency is far easier when the numbers are a by-product rather than an exercise.
White paper
Meeting accessibility and audit expectations in digital services
A practical account of building services that can be assessed: accessibility standards in the delivery process, audit trails that answer real questions, and documentation that survives a handover.
Our work
Let’s talk
Have a problem you need to solve or an idea you want to explore? Let’s talk about how we can make it happen.