Public-sector software

Modern software.
Accountable public services.

AI changes the cost and speed of building software. It does not change a public body’s obligation to produce the right answer, show its working and remain accountable for it.

We build complete civic applications and modernise existing systems, with lower build and running cost as explicit design goals. Caseworkers need the next obligation in view; leaders need a service they can inspect, change and keep running. Both need the history to survive.

Discuss a public service

Work in the open

Claims, status and boundaries are stated plainly.

live

Phoenix Ember

A live education assessment, intervention and evidence product in school use. Zero Drift is PECTECH’s contracted software builder.

See the product and our role →
design

Phoenix Eyrie

A local-authority SEND and EHCP casework product in design: needs assessment, panels, statutory clocks and appeals. It is not presented as live.

See its current status →
2,510 → 0

Measured replacement

Recorded observations compared across Ember’s old and replacement servers, with zero differences inside the measured boundary.

Read the evidence and its limits →
A modern London civic service building has an accessible ramp and one calm public entrance. Behind and below it, permissions, case clock, policy records, appeal facts and recovery machinery feed one continuous blue route; a giant configuration cabinet recedes behind.

The real requirement

Complexity is not a reason to buy something enormous.

A public service rarely has one neat workflow. It has legislation, policy, local practice, accessibility needs, safeguarding, multiple professions, reporting duties, appeals, integrations and records that outlive the people who created them. Remove one head and two more appear.

That is why generic enterprise packages become expensive: the organisation pays for licences, implementation, configuration, integration and workarounds, then keeps paying whenever the real service changes. The software may be large without ever fitting the work.

Why this matters now

An ageing estate is a service problem.

The government’s January 2025 State of Digital Government Review estimated that 28% of central-government systems were legacy in 2024. In its survey, 70% described a data landscape that was not well coordinated or interoperable and did not provide a unified source of truth. Only 27% believed their data infrastructure enabled a comprehensive view of operations or transactions.

Read the government review →
28%

of central-government systems estimated to be legacy in 2024.

70%

of survey respondents described a fragmented data landscape.

27%

believed their data infrastructure enabled a comprehensive operational or transactional view.

Those figures describe the scale of the estate, not a forecast of what one programme will save. The opportunity is practical: modern construction methods let smaller teams tackle more of the real requirement, while explicit contracts and mechanical evidence keep the result governable.

A practical division of work

Keep rules explicit and decisions accountable.

A model can help draft an explanation or build the implementation. Recorded inputs and versioned rules govern calculations, permissions and workflow state; an accountable professional owns decisions requiring judgement. Deterministic code is not automatically correct: the rule and implementation both need evidence.

Inspect the reasoning behind this boundary →

A route out of legacy

Keep the service. Replace the constraints around it.

Old software contains years of real behaviour, including awkward cases nobody wrote down. A safe replacement begins by discovering and measuring that behaviour, not by pretending a blank sheet means a simple problem.

  1. 01

    Recover the truth

    Document workflows, rules, data, integrations, exceptions and the behaviour of the live system.

  2. 02

    Separate the domains

    Turn an entangled estate into bounded capabilities that can change and scale independently.

  3. 03

    Build behind a measured boundary

    Run old and new paths against the same observations; keep a rollback route until equivalence is evidenced.

  4. 04

    Retire deliberately

    Move only when the evidence says the replacement preserves what matters, then remove the cost of the old path.

What changes commercially

A product the organisation can own, operate and afford.

Complete service. The difficult workflows, migration, security, accessibility, operations and handover are part of the agreed product.

Controlled boundaries. Separate domains let a service change one part without making every change a whole-estate replacement.

Traceable decisions. Rules and state transitions are explicit; consequential actions retain evidence of the input, rule version and responsible person.

A cost case you can challenge. Compare implementation, migration, licences, hosting, support and future change over an agreed period. AI-assisted construction is a way to reduce repeated engineering work; savings must be established for the actual service.

Evidence for the buying decision

Make the commitment inspectable.

A lower price is not enough. Before a public organisation commits, its service, technology and procurement teams need to understand what they are buying and how they could operate or leave it.

The service contract

Named workflows, exceptions, accessibility requirements, integrations and acceptance evidence. Every important requirement should connect to a delivered behaviour and a check someone can repeat.

The data and continuity plan

Data ownership, access boundaries, retention, export, migration reconciliation, recovery and rollback. Long-lived records remain part of the service even when the application changes.

The supplier and operating record

Named responsibility, support arrangements, operating costs, security evidence and the corporate information the buyer requires. Confirm the applicable procurement route and contractual obligations with the organisation’s own team.

Inspect our corporate and procurement record → See commercial terms → Take the decision pack to your team →

Where to begin

Start with the risk, not a replacement programme.

An initial review uses the material the organisation already has—contracts, architecture, service data, policy, source access and the people who know the exceptions. We map what must be preserved, what can change, how incumbent suppliers participate and what evidence will permit a safe move. The organisation receives the specification, risk register, options and operating knowledge; it is not trapped inside our proposal.

01

Establish what is true.

Map architecture, obligations, data, delivery controls and the gap between claimed and evidenced completion.

02

Change a live system safely.

Recover behaviour, separate domains and build the replacement behind a measured equivalence and rollback boundary.

03

Build the complete service.

Compile the requirement, implement the difficult workflows and hand over a deployed, supportable product rather than a demonstration.

Modernise a public service without making its rules approximate or its judgement unaccountable.

Tell us what has to hold