Industry
Software engineering for Government & Public Sector
Public sector software is hard for reasons that have nothing to do with the code: procurement rules that shape delivery before a line is written, accessibility that is a legal duty rather than a nice-to-have, a legacy estate that cannot simply be switched off, and public accountability that means every decision may be examined. We build to the Service Standard, treat WCAG as the floor, and are honest about what modernisation actually costs.
Why the domain matters
Government software is not commercial software with a crown on it. It is delivered under the GDS Service Standard and the Service Manual, procured through frameworks that constrain how you engage a supplier before anyone writes code, accountable to the public and to Parliament in a way no private product ever is, and held to accessibility as a matter of law rather than taste. A public service has to work for everyone who is entitled to use it, including people with disabilities, people on poor connections, people who do not trust or cannot afford the alternative, because there usually is no alternative. That single fact changes how the whole thing must be built.
The sector also has a shape worth naming, because software lands differently across it. Central government departments run large transactional services and vast legacy back-ends, and deliver against the Service Standard with assessments at alpha, beta and live. Local authorities run a sprawling set of statutory services (housing, council tax, benefits, social care, waste, planning), often on ageing line-of-business systems from a handful of dominant suppliers, with far tighter budgets and less in-house engineering. Arm’s-length bodies, the NHS, and the devolved administrations each add their own standards and constraints. What unites them is that the citizen is not a customer who can be lost, the data is frequently sensitive and statutory, and the accountability is public. Software that ignores any of that does not just underperform: it can exclude people or expose the organisation.
We are a senior-led team and we operate what we build, so we start from the obligations and the existing estate rather than from a product we would like to sell. In the public sector the hard part is almost never the interface. It is getting through procurement honestly, meeting accessibility as the legal duty it is, modernising legacy without breaking a live statutory service, and building something that survives public scrutiny and a service assessment. We would rather do the unglamorous work of migration, accessibility and open standards properly than ship a demo that passes a show-and-tell and then fails an assessment or excludes a user. We are engineers who understand how the public sector actually delivers, and we are honest about the trade-offs from the start.
The challenges in government & public sector
Procurement shapes delivery before code is written
Public bodies buy through frameworks. G-Cloud for off-the-shelf cloud and support, the Digital Outcomes route for bespoke teams and delivery, and the framework you use, the way the requirement is written, and the evaluation criteria all constrain how the work can run before anyone opens an editor. Procurement is not paperwork to get past; it is part of the delivery model. A plan that ignores how the work was bought, or that assumes commercial flexibility the framework does not allow, runs into trouble that has nothing to do with engineering.
Accessibility is a legal duty, not a quality nice-to-have
Public sector websites and apps must meet WCAG to the level the accessibility regulations require, publish an accessibility statement, and genuinely work for assistive technology. This is law, backed by monitoring, not an internal quality target you can trade away under deadline pressure. It has to be designed in from the first wireframe and tested with real assistive technology, because retrofitting accessibility onto a finished product is expensive, incomplete, and still leaves the organisation exposed.
A legacy estate that cannot simply be switched off
Much of government runs on old, business-critical systems, mainframes, dominant-supplier line-of-business platforms, databases that are the statutory record for millions of people. These cannot be turned off for a rewrite, because the service they run is live and often has no fallback. Modernisation means integrating with, strangling, or carefully migrating off systems that are simultaneously fragile, poorly documented, and essential. Any plan that assumes greenfield ignores the estate the service actually depends on.
Public accountability and scrutiny of every decision
A government service is accountable in ways a private product is not: subject to Freedom of Information, to audit, to Parliamentary and press scrutiny, to service assessments, and to the reasonable expectation that decisions can be explained. That shapes the software: the audit trails it must keep, the transparency it must offer, the automated decisions it must be able to justify. Building as though nobody will ever ask how or why the system did something is how public projects generate scandals rather than services.
Cross-department data sharing that is legally and technically hard
Joining data across departments or between central and local government is where a lot of citizen value lives (tell-us-once, joined-up services, fraud prevention), but it is constrained by data protection law, by the legal basis for sharing, by inconsistent identifiers and formats, and by a justified caution about surveillance and function creep. The technical integration is only half the problem; the lawful, proportionate, well-governed basis for the sharing is the other half, and neither can be skipped.
Delivery under budget scrutiny and the Service Standard together
Public delivery is squeezed between two forces: the Service Standard and its assessments, which demand user research, accessibility, open standards and iterative delivery done properly; and public-money scrutiny, which demands value, transparency of spend, and avoidance of the failed-programme headlines the sector is famous for. Meeting both means being honest about scope and cost, resisting the big-bang programme, and delivering in assessable increments, which is a discipline, not a slogan.
What we build for government & public sector
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Citizen-facing transactional services
End-to-end services that let people apply, report, pay, book or check status, built to the Service Standard, with user research, accessibility and iterative delivery through alpha, beta and live. We design for the whole population entitled to use the service, including people using assistive technology and people on poor connections, because a public service that only works for confident users has failed the ones who most need it. The front end is the easy part; the value is in the honest workflow and the integration behind it.
Legacy modernisation and migration
Modernisation of the back-office and line-of-business estate without switching off a live statutory service, strangler-pattern replacement, careful data migration, and integration layers that let new services front old systems while they are gradually retired. We treat the legacy system as fragile, essential and poorly documented, because it usually is, and we plan the migration and rollback deliberately rather than betting a live service on a single cut-over.
Back-office and case-management systems
The operational systems that caseworkers, officers and administrators actually use to deliver statutory services, case management, workflow, eligibility, records. These are unglamorous and high-value: reliability, clear workflow, a defensible audit trail and accessibility for staff who also have a legal right to accessible tools matter far more than novelty. We build for the person processing the hundredth case of the day, not for the show-and-tell.
Cross-department and data-sharing platforms
Integration and data-sharing between departments, agencies and local government, built on a proper legal basis and open standards, with the governance, minimisation and audit that lawful sharing requires. We treat the legal basis and proportionality as part of the engineering, not a box ticked afterwards, because cross-government data sharing that is technically slick but legally and ethically careless is exactly how these initiatives collapse.
APIs, open standards and platform components
Reusable APIs, open-standard data exchanges and platform components that let services be joined up and reused rather than rebuilt in every silo. We build to published open standards and government API guidance, publish clear documentation, and design for reuse and interoperability, because the public sector pays repeatedly when every service invents its own incompatible way of doing the same thing.
Accessible design systems and front-ends
Front-ends built on accessible, consistent components (aligned with the GOV.UK Design System where appropriate), that meet WCAG as the floor and are tested with real assistive technology. Using a proven design system is not about looking official; it is about inheriting patterns that are already accessible and well-researched, so effort goes into the service-specific hard parts rather than re-solving problems the sector has already solved.
Where we help
A citizen service that passes its beta assessment and works for everyone
A body needs a transactional service (an application, a report, a booking), delivered to the Service Standard. The real work is user research across the whole population entitled to use it, accessibility tested with assistive technology rather than assumed, iterative delivery through alpha and beta, and honest integration with the back-end systems the transaction actually depends on. Get that right and the service passes assessment and serves people who have no alternative; treat the standard as a hoop and it fails the assessment and the users at once.
Strangling a legacy line-of-business system without an outage
An authority is dependent on an ageing statutory system that cannot be switched off but is increasingly costly and fragile. We put an integration layer in front, migrate capability incrementally using the strangler pattern, move data carefully with reconciliation and rollback planned from the start, and retire the old system only when the new path is proven. The measurable win is a live service that keeps running throughout, rather than a big-bang cut-over that risks a statutory outage nobody can afford.
A joined-up service that shares data lawfully across bodies
Two or more public bodies want to reduce the burden of citizens telling the same thing to government repeatedly, or to share data to deliver a joined-up outcome. We build the integration on an explicit legal basis, with data minimised to what the purpose needs, governance and audit built in, and proportionality treated as a design constraint. The value is a genuinely joined-up service; the discipline is refusing to build data sharing that is technically easy but legally or ethically unjustified.
A back-office case system caseworkers will actually rely on
Officers delivering a statutory service are stuck with a slow, error-prone or unsupported tool. We build case management around how they really work: clear workflow, reliable records, a defensible audit trail for decisions that may be examined, and accessibility because staff have the same legal right to accessible tools as the public. The win is faster, more consistent, more defensible casework, delivered by a system built for the hundredth case of the day rather than the demo.
How we build for the public sector
We start from the Service Standard, the obligations and the existing estate, not the screens. Before designing anything we want to understand how the service is delivered today, which legacy systems it depends on, what the legal and accessibility duties are, and how the work was procured, because in government all four of those shape delivery more than any design decision. We design for the whole population entitled to use the service and for the caseworkers behind it, not for a confident demo audience.
We treat accessibility and user research as non-negotiable inputs from the first wireframe. Accessibility is a legal duty, so it is designed in and tested with real assistive technology throughout, never retrofitted at the end. User research spans the range of people who must be able to use the service, including those the digital-by-default assumption tends to exclude. This is not process for its own sake; it is what the Service Standard requires and what stops a service failing an assessment or, worse, excluding the people who most need it.
We plan legacy modernisation as careful, incremental, reversible work. The estate is fragile and essential, so we favour strangler-pattern replacement, integration layers and staged migration with reconciliation and rollback planned from day one, over big-bang rewrites that bet a live statutory service on a single cut-over. We are honest that this is slower and less glamorous than a clean rebuild, and that honesty is precisely what protects the service that citizens depend on.
Because we operate what we build, the people designing a service or a migration are the ones accountable when something needs explaining to an auditor, a data-subject request, or a service assessment. That keeps us focused on the failure modes that matter in the public sector (exclusion, an unexplainable automated decision, a migration that loses statutory records), and honest about trade-offs and cost up front, rather than generating the kind of failed-programme headline the sector is unfairly and fairly known for.
Regulation and compliance
The GDS Service Standard and the accompanying Service Manual set how public services should be designed and delivered, with assessments at alpha, beta and live for services in scope. They are not optional style guidance: they cover user research, accessibility, open standards, iterative delivery, security and more, and a service can be stopped at assessment for failing them. We build to the Standard because it is the framework the sector holds delivery to, and because most of what it asks for is simply how good public software should be built.
Accessibility is a legal duty under the public sector accessibility regulations. Public sector websites and mobile apps must meet WCAG to the required level, publish an accessibility statement, and be genuinely usable with assistive technology, subject to monitoring. We treat WCAG as the floor rather than the ceiling, design for it from the outset, and test with real assistive technology, because this is enforceable law and, more importantly, because a service that excludes disabled users has failed at its core purpose.
Procurement itself is a regulated activity. Public bodies buy digital work through frameworks such as G-Cloud and the Digital Outcomes route, under public procurement rules that govern fairness, transparency and value for public money. The framework and the way a requirement is specified constrain how the work can be delivered, so we engage with procurement as part of the delivery model rather than an obstacle, and we are straight about what a given route does and does not allow.
Data protection under UK GDPR and the Data Protection Act, transparency obligations including Freedom of Information, and the lawful basis for any data sharing all sit across the work. Public bodies hold statutory, sensitive data and are accountable for how they use it. We engineer for lawful basis, minimisation, retention and a defensible audit trail from the start. To be clear about the boundary: we are engineers who build to these obligations, not your legal, information-governance or SIRO function, accountability for them rests with the public body, and we build to work alongside the people who hold it.
Integration
The legacy estate is the gravitational centre of public sector integration. Central departments and local authorities run business-critical systems (mainframes, dominant-supplier line-of-business platforms, statutory databases), that cannot be switched off, so new services almost always have to front, integrate with, or migrate off them. We build integration layers and use the strangler pattern to modernise around these systems while they are gradually retired, treating them as fragile, essential and poorly documented, because that is what they usually are.
Government platforms and shared components are the other side of the picture. Where they fit, we integrate with cross-government building blocks (identity and verification, notifications, payments and the design system), rather than rebuilding them, because reuse is both cheaper and more consistent than every service inventing its own. We build to published government API and open-standard guidance so that services can be joined up and reused rather than re-implemented in every silo.
Cross-department and central-to-local data sharing is where a lot of citizen value and a lot of risk both sit. We integrate on an explicit legal basis, with data minimised to the purpose, identifiers and formats reconciled across systems that were never designed to agree, and governance and audit built in. The technical integration is only half the job; the lawful, proportionate, well-governed basis for the sharing is the other half, and we treat both as core engineering.
The recurring integration problem across all of this is consistency and identity: the same citizen, property or case represented differently across departments, suppliers and registers, with no clean shared key. We treat reconciliation, matching and open-standard data exchange as first-class work rather than an afterthought, because a joined-up service is only as trustworthy as its ability to know that two records really are the same person, and getting that wrong in government harms real people.
Security and data protection
Public sector systems hold statutory and often highly sensitive data about the whole population (identity, benefits, health, social care, tax, immigration status), and are a standing target. We build to NCSC guidance and the government security expectations, with data classification driving how information is handled, access controls scoped to genuine need, encryption in transit and at rest, and retention limited to what a lawful basis supports. Security here is not a bolt-on; it is a condition of the service being allowed to run at all.
Data classification shapes the architecture, not just the paperwork. How data is classified determines where it can live, who and what may touch it, and how it must be separated, so we design to the classification of the data the service actually handles, following NCSC principles rather than a generic template. The most sensitive flows deserve the strictest handling: narrower access, clear purpose limitation, and deliberate thought about who ever needs to see a given record.
Public accountability makes the audit trail a security and governance deliverable, not an optional log. A government system may have to explain, to an auditor, a court, a data-subject request or a Freedom of Information request, exactly what it did and why, including any automated decision it made about a person. We build the ability to reconstruct what happened, and to justify automated decisions, into the system deliberately, because in the public sector an unexplainable action is not just a bug, it is a governance failure.
Because we operate what we build, security and monitoring are part of the deliverable rather than a report handed over at the end. We instrument for the access patterns and anomalies that indicate a problem, keep the audit trail an investigation or a scrutiny process would need, and treat resilience and the ability to recover statutory data as core, because when the data is statutory and the service has no commercial alternative, losing it or leaking it does public harm, not just reputational damage.
What changes
Services that pass assessment and work for everyone
Because we build to the Service Standard and treat accessibility as the legal floor it is (designed in, tested with real assistive technology), services meet their assessments and genuinely serve the whole population entitled to use them, including the people who have no alternative and whom lazy digital-by-default tends to exclude.
Legacy modernised without breaking the live service
By favouring strangler-pattern replacement, integration layers and staged, reversible migration over big-bang rewrites, the statutory service keeps running throughout modernisation (no cut-over gamble, no lost records), which is the difference between a quiet, successful transition and the kind of failed-programme headline the sector is known for.
Decisions and data that stand up to public scrutiny
Because we build defensible audit trails, explainable automated decisions and lawful, minimised data handling in from the start, the service can answer an auditor, a court, an FOI request or a data-subject request, which is what public accountability actually demands and what protects the organisation from the scandal that opaque public systems generate.
What we build for government & public sector
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for government & public sector?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in government & public sector choose us
We build to the Service Standard because we understand why it exists
We deliver to the GDS Service Standard and Service Manual not as hoops but as the discipline that stops public services failing their users, user research, accessibility, open standards and iterative delivery done properly. We design for the whole population and the caseworkers behind the service, so the work passes assessment because it is genuinely good, not because it was dressed up for a show-and-tell.
We treat accessibility as the legal duty it is
Accessibility is enforceable law in the public sector, and we design for WCAG as the floor from the first wireframe, tested with real assistive technology rather than assumed. A service that excludes disabled users has failed at its core purpose and exposes the organisation, so we build it in from the start instead of retrofitting it expensively and incompletely at the end.
We modernise legacy without gambling on the live service
The public sector estate is fragile and essential, and we treat it that way, strangler-pattern replacement, integration layers and staged, reversible migration over big-bang rewrites. We are honest that this is slower than a clean rebuild, because that honesty is exactly what protects a statutory service citizens depend on and keeps a modernisation off the failed-programme front pages.
We operate what we build, so accountability is designed in
The people who design a service or a migration are the ones who have to explain it to an auditor, a data-subject request or a service assessment. That keeps us focused on the public sector failure modes that matter (exclusion, an unexplainable decision, a migration that loses statutory records), and honest about cost and trade-offs up front rather than in a post-mortem.
Common questions
Do you work to the GDS Service Standard and Service Manual?
Yes, and we build to them because we understand why they exist rather than treating them as hoops to jump through. The Standard and the Service Manual cover user research, accessibility, open standards, iterative delivery and security, with assessments at alpha, beta and live for services in scope. We design for the whole population entitled to use a service and for the caseworkers behind it, so the work passes assessment because it is genuinely good (accessible, researched and honestly integrated), not because it was dressed up for the show-and-tell.
How do you handle accessibility, and is meeting WCAG really mandatory?
Accessibility is a legal duty under the public sector accessibility regulations, not a quality nice-to-have. Public sector websites and apps must meet WCAG to the required level, publish an accessibility statement, and genuinely work with assistive technology, subject to monitoring. We design for it from the first wireframe and test with real assistive technology throughout, treating WCAG as the floor rather than the ceiling. Retrofitting accessibility onto a finished product is expensive, incomplete and still leaves the organisation exposed, so we never leave it to the end, and a service that excludes disabled users has failed at its core purpose.
Can you modernise our legacy systems without taking the service down?
That is usually the whole point, and we plan for it from the start. The public sector estate is full of business-critical systems that cannot simply be switched off, so we favour strangler-pattern replacement, integration layers and staged, reversible migration over big-bang rewrites. We put a new path in front of the old system, migrate capability and data incrementally with reconciliation and rollback planned from day one, and retire the legacy system only once the new path is proven. We are honest that this is slower than a clean rebuild, and that honesty is exactly what protects a live statutory service from a cut-over gamble nobody can afford.
How do you engage with public procurement. G-Cloud, Digital Outcomes and the rest?
We treat procurement as part of the delivery model, not an obstacle to get past. Public bodies buy through frameworks. G-Cloud for off-the-shelf cloud and support, the Digital Outcomes route for bespoke delivery teams: under public procurement rules, and the framework and the way a requirement is written constrain how the work can run before any code exists. We engage with that honestly, are straight about what a given route does and does not allow, and shape delivery to fit the procurement rather than pretending it away. We are not your commercial or procurement advisers, but we understand the routes well enough to deliver within them.
How do you handle cross-department data sharing and public accountability?
Carefully, and on an explicit legal basis. Joining data across departments or between central and local government carries real citizen value and real risk, so we build the integration on a clear lawful basis, minimise data to what the purpose needs, reconcile inconsistent identifiers across systems that were never designed to agree, and build governance and audit in. On accountability, a public service may have to explain to an auditor, a court, an FOI request or a data-subject request exactly what it did and why (including any automated decision about a person), so we build defensible audit trails and explainable decisions in from the start. The technical integration is only half the job; the lawful, proportionate basis is the other half, and we treat both as core engineering while accountability for the governance rests with the public body.
Building for government & public sector?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if government & public sector is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.