Public services, engineered to serve everyone.
Citizen-facing services, case-management systems and legacy modernisation for government — accessible, auditable, sovereign.
- Service and estate discovery
- Prototype and accessibility baseline
- Build the thread
- Parallel run and cutover
- Operate, measure, hand over
Government software has the hardest requirements of any sector we work in.
Every citizen is a user, which means the service must work for someone on an old phone over a weak connection, for someone using a screen reader, and for someone who will attempt the form once and never return if it fails. Accessibility is law rather than preference. Data sovereignty is not negotiable. And the legacy estate votes every day: a registry written decades ago still holds the record, still runs the country’s business at eight o’clock on a Monday, and cannot be switched off while something better is built.
We build digital services designed to be finished on the first try — and modernise the systems behind them with continuity as the first constraint. That means designing the citizen journey and the officer’s case file as one system rather than two projects, because a beautiful front end over an unchanged back office simply moves the queue. It means treating the audit trail as a product requirement, since every decision an institution makes may be challenged, reviewed or subject to a freedom-of-information request years later. And it means writing for procurement: milestones, documentation and evidence that an oversight body can read without an interpreter.
Sovereignty is a design input, not a deployment detail. Our platforms and practice support on-premise, national-cloud and air-gapped operation, with data residency, retention and access decided per institution and documented. KVKK and GDPR obligations are built into the data model — minimisation, purpose-bound access, encryption, audit logging — rather than added by a policy document after go-live.
Four kinds of work, from the citizen to the registry.
Public-sector programmes fail at the joins — between the form and the case file, between the new service and the system that still holds the record. These are the four pieces we build, and we prefer to build them as one thread.
Citizen services
Application, permit and benefit journeys — accessible to WCAG standards, usable by design, measured by completion rates. We instrument the journey step by step so the institution can see where people abandon and why, and we treat a drop-off at the evidence-upload step as a defect rather than a fact of life. Content, error messages and eligibility questions are tested with real users, including users of assistive technology, before launch — not audited afterwards. Built with our design practice and delivered on the stack described in web application engineering.
Case management
Workflow systems for the officials behind the service — queues, decisions, documents and full audit trails. Work is routed by rule rather than by whoever noticed it, deadlines are visible before they are breached, and every decision carries its author, its timestamp, the evidence it rested on and the rule version in force at the time. Officers get the whole file in one place instead of three systems and a shared drive, and supervisors get a workload picture that does not require anyone to compile a spreadsheet.
Legacy modernisation
Strangler-pattern re-engineering of ageing registries and departmental systems, with continuity as the first constraint. New capability is built alongside the old system, traffic is moved function by function, and the record stays consistent throughout because the two run in parallel until the numbers agree. The techniques are the ones described on our legacy re-engineering and modernisation pages — characterisation tests, change data capture, reversible cutovers.
Data & interoperability
Governed data exchange between institutions — standards-based, logged, and privacy-preserving. Each exchange has a legal basis, a named purpose, a minimal field set and a retention period, and every access is logged in a form an oversight body can read. Where volumes or latency demand it we run the exchange on an event backbone with replay and dead-letter handling, so a downstream institution’s outage becomes a backlog rather than a hole in the record.
What we build, in detail.
A journey measured by who finishes it.
The honest measure of a public service is the share of people who complete it on the first attempt, unaided. Everything else — page views, satisfaction scores, the launch event — is a proxy. We design each journey around the smallest set of questions the decision actually requires, ask for evidence only when it changes an outcome, and save progress at every step so an interrupted application survives a lost connection or a borrowed phone. Where the institution already holds a fact, the service should not ask the citizen for it again.
- Every step instrumented for start, completion, abandonment and error, so the weakest point in the journey is visible once live traffic starts
- Assistive-technology testing in the build, not before the launch — keyboard-only paths, screen-reader labels, focus order and error announcement all checked as part of the definition of done
- Progress saved server-side with a resumable reference, and a paper or assisted-digital route designed alongside the online one rather than left to the call centre
- Plain-language content and error messages written with the policy team, so a rejection explains what to do next instead of quoting a regulation number
- 01Start
- 02Identity
- 03Evidence
- 04Review
- 05Decision
Permit application journey
The officer’s queue, with the deadline in view.
Behind every citizen journey is a person who has to decide something, usually against a statutory clock and usually with the file spread across a case system, a document store and an inbox. The case management systems we build put the whole file on one screen: the application, the evidence, the checks already run, the previous decisions on the same subject, and the rule set in force. Routing is a configured rule — by type, region, value or complexity — so work reaches the right desk without a supervisor triaging it by hand.
- Statutory deadlines tracked per case with escalation before breach, not a report about breaches afterwards
- Every decision recorded with actor, timestamp, evidence references and the version of the rule applied — the record an appeal or an audit will need years later
- Four-eyes approval, delegation and substitution as configuration, so an absence does not stall a queue
- Documents held once with versioning and access logging, and released to the citizen through the same governed record rather than by email
Modernisation in parallel with the live service.
Nobody gets to close a registry for a weekend. So we do not attempt a big-bang replacement: we put a governed interface in front of the old system, build the new capability behind it, and move one function at a time. Change data capture keeps the two stores in agreement during the overlap, characterisation tests pin the old system’s behaviour — including the behaviour nobody documented and everybody depends on — and every cutover has a rehearsed way back that has been used at least once in a drill before it is needed in earnest.
- Characterisation tests written against the legacy system’s real outputs before a line of it is replaced
- Parallel running with automated comparison until the two systems agree on production data for an agreed period
- Function-by-function cutover behind a routing layer, reversible, scheduled outside service hours and announced in advance
- The historical record migrated with validation and a documented lineage, because a registry without its history is a new system, not a modernised one
Three audiences, one accountable system.
One attempt should be enough.
The citizen’s measure is simple: did the service work, on the device they own, in the time they had, without a phone call. We design for the weakest case — an old handset, an intermittent connection, a first-time user with limited digital confidence — because a service that works there works for everyone. Language is plain, the next step is obvious, and a rejection says what to do about it.
- WCAG 2.1 AA verified with assistive technology, not only automated checks
- Resumable applications and status visible without a login where privacy allows
- Assisted-digital and paper routes designed alongside the online journey
Decisions that defend themselves.
An officer needs the file, the rule and the clock — and needs the system to record what they did in a form that will survive review. Routing rules put work on the right desk, checks that can be automated are run before the file is opened, and the decision screen shows the evidence next to the criterion it satisfies. The audit record is written as a by-product of the work rather than as a separate act of documentation.
- Configurable routing, thresholds and four-eyes approval per case type
- Complete decision history with rule versions, exportable for appeals and oversight
- Workload and deadline view for supervisors, computed rather than compiled
Sovereign, operable and documented.
The institution’s IT function inherits whatever is delivered, so it has to be operable by its own people on its own infrastructure. We deploy where the law and the policy require — on-premise, national cloud or air-gapped — with infrastructure as code, documented runbooks and monitoring that your team can read. What is handed over is set in the contract for each engagement, and we are content to be the engineering core inside a larger programme run by a system integrator.
- On-premise, national-cloud or air-gapped deployment with infrastructure as code
- Interoperability through published, versioned interfaces rather than direct database access
- Security and logging aligned with our security practice
The systems an institution already runs.
National identity & e-government gateways
Authentication and attribute retrieval through the national gateway, with the minimum attribute set requested and every retrieval logged against its purpose.
Electronic signature & seal
Qualified signature on decisions and documents, with the signed artefact, its timestamp and its validation evidence retained together for the statutory period.
Registries of record
Population, land, vehicle, business or licence registries read through published interfaces or a change-data-capture feed — not by a direct query against another institution’s database.
Document management & archives
Records filed against the institution’s classification scheme with retention and disposal rules applied automatically, so archiving is a system behaviour rather than an annual project.
Payments, revenue and financial management
Fees and fines collected through the institution’s existing payment provider and reconciled to the case record, so a payment can be tied to the decision it belongs to — with commitments, receipts and budget lines exchanged with the finance system through governed interfaces that keep the accounting record authoritative.
Notification channels
SMS, e-mail and mailbox notifications sent from the case record with delivery status stored, so a claim that a citizen was never told can be answered with evidence.
Geospatial systems
Parcel, zoning and asset data served from the institution’s GIS into permit and inspection journeys, so an application is validated against the map rather than a typed address.
Reporting & open data
Statistical extracts and open-data publication generated from the same record, aggregated and anonymised to an agreed disclosure standard, with our data engineering practice owning the pipelines.
Our default approach, and what is decided with you.
How we work with an institution.
- Accessibility as law, not aspiration. WCAG 2.1 AA is a build requirement checked in the pipeline and verified by hand with screen readers, keyboard-only navigation and magnification. A journey that passes automated checks but defeats a screen-reader user has not passed.
- Data sovereignty by deployment choice. On-premise, national-cloud and air-gapped operation are all supported, with the same infrastructure-as-code and monitoring in each. Residency, retention and cross-border questions are answered in the design phase and written down.
- KVKK-first data handling with institutional protocols. Minimisation, purpose-bound access, encryption at rest and in transit, and access logging that an oversight body can read. Personal data is mapped field by field with its legal basis and retention period.
- Procurement-compatible delivery. Milestones, acceptance criteria, documentation and transparent reporting, in the form the contract requires — and progress evidenced by working software at each milestone rather than by status decks.
- Continuity is the first constraint. Modernisation runs in parallel with the live service, cutovers are reversible and rehearsed, and phases are planned to avoid a window in which citizens cannot be served.
- The record outlives the project. Decisions, evidence and rule versions are retained in a form that will still answer an appeal or an audit years later, independent of the interface that captured them.
- Handover as a deliverable. What is handed over is set in the contract for each engagement. We are equally comfortable operating the platform under a support agreement or stepping back once your team is ready.
- We work inside larger programmes. As the engineering core alongside a system integrator, with clear interface ownership and joint acceptance criteria rather than a boundary dispute.
How a public-sector programme runs.
Service and estate discovery
We map the journey as citizens actually experience it, the decision process as officers actually run it, and the systems that hold the record. Legal basis, data fields, retention and the deployment target are agreed here — with the institution’s legal and IT security functions in the room, not consulted afterwards.
Prototype and accessibility baseline
A working prototype of the highest-volume journey, tested with real users including users of assistive technology, plus the case-management skeleton behind it. Accessibility conformance is established at this point so it constrains the build instead of surprising it.
Build the thread
The citizen journey, the officer’s case file and the integrations that connect them, delivered in working increments against the milestone plan. Interfaces to identity, registries and payments are contract-tested, and the audit record is verified against the evidence an appeal would require.
Parallel run and cutover
Where a legacy system is being replaced, both run together with automated comparison until the outputs agree on production data. Independent penetration testing and an accessibility audit complete before go-live, and the cutover is rehearsed with a documented way back.
Operate, measure, hand over
Completion rates, error points and deadline performance are monitored and reported. Improvements ship at a rhythm agreed with you, and the platform is either operated by us under a support agreement or handed to your team with runbooks and training.
Frequently asked questions
Neighbouring sectors we work in.
Bring us a problem from your industry.
Describe what is going wrong today. An engineer reads it and replies in writing with a concrete path.