Public Sector
Public sector software has a user base it cannot choose and cannot ask to upgrade a browser. That single fact rules out a lot of otherwise reasonable engineering decisions.
You do not get to pick your users
A commercial product can accept that some proportion of visitors will not manage to use it. A statutory service cannot. If someone must renew a licence or claim a benefit, then an interface that fails on an old device, a slow connection, or with a screen reader is not a conversion problem — it is a person unable to access something they are entitled to.
That makes accessibility and progressive enhancement requirements rather than preferences, and it usually means less client-side complexity than a comparable commercial build. Server-rendered pages that work without JavaScript are not a nostalgic choice here; they are the only way to reach everyone who has to be reached.
Where we work
Citizen-facing services
Applications, renewals and payments built to work on old devices, poor connections and assistive technology.
Case management
Caseworker tools with the audit trail, delegation and retention that public accountability requires.
Legacy modernisation
Replacing systems that have run for decades, incrementally, without a cutover weekend that ends up in the press.
Open data and transparency
Publishing datasets with schemas and provenance stable enough that third parties can build on them.
Identity and eligibility
Verification and entitlement checking with a documented path for people whose circumstances the rules did not anticipate.
Internal platforms
Shared infrastructure and standards so individual departments stop solving the same problem separately.
Built to be handed over
A procurement cycle will eventually move the work to another supplier, or in-house. Software that only its original vendor can maintain converts that transition into a rebuild, at public expense. This is the strongest argument for boring technology and thorough documentation, and it is why we make handover a deliverable rather than a phase.
In practice that means widely known languages and frameworks over interesting ones, infrastructure defined in code, and architecture decisions recorded with their reasoning. A future team should be able to understand why the system is shaped this way without finding anyone who was there.
WCAG 2.2 AA verified with assistive technology, not just automated checks
Works without JavaScript for anything statutory
Widely known technology chosen deliberately over novel technology
Records retention and disposal designed in, per your schedule
Architecture decision records, so the next supplier inherits the reasoning
Common questions
Generally yes, and we would rather understand the constraints early than design something the framework cannot buy. Tell us the route and the evaluation criteria at the outset; they often shape sensible architecture as much as the requirements do.
Keep exploring.
Ready to start your project?
Get a free technical discovery call. We'll map the right team, stack, and timeline to match your goals — no obligation.