Long asset lives
Infrastructure is measured in decades. Software with a three-year shelf life is a liability being installed deliberately.
Energy & utilities
Software that has to be right for twenty years.
Utilities buy on a different timescale. The system you build will outlast the team that built it, the vendor relationships around it and probably the technology choices inside it. That changes what good looks like: documentation, boring technology and a genuine handover matter more here than they do anywhere else, and cleverness is a liability. Good energy and utilities software development is judged by whether a stranger can still run the system in twenty years.
The question to answer first
“Who maintains this when none of us are here?”
20yr
The kind of horizon utility software is expected to serve
The pressure
Four things that make utility procurement different.
Regulated returns
Spending is scrutinised and has to be justified to a regulator, which changes how a business case must be written.
Distributed generation
The grid was designed to flow one way. It no longer does, and most of the supporting systems still assume it does.
Critical national infrastructure
Security expectations are set by the consequence of failure, not by the size of the IT budget.
The work
What we build for utilities
Four systems, all of which will outlast every person involved in specifying them.
Asset management
Condition, maintenance history and replacement planning across assets that are older than the records describing them.
Metering and settlement
High-volume ingestion and reconciliation where errors are customer bills and regulatory findings.
Outage and field systems
Dispatch, restoration and customer communication during the exact period everything is under strain.
Customer platforms
Billing, tariffs and self-service, which is the only part of the utility most customers ever experience.
The handover
What you receive, and what it means you never have to call us.
In a sector that procures against decades, the exit is not an afterthought. It is the thing being bought. The first four items are part of every engagement we run. The supervised period is something we propose and agree in writing.
01
On delivery
The source, with its history
The full repository including commit history, in your organisation, under your account. Not an export. Not a zip file. The actual history, because that is where the reasoning lives.
02
On delivery
A runbook a stranger can follow
How to deploy it, how to roll it back, what breaks first, what each alert means and who would normally be called. Written for someone who has never met us.
03
On delivery
The decisions, and why
An architecture decision record for every significant choice, including the options rejected. In twenty years this is worth more than the code.
04
On delivery
Infrastructure as code
The environment is reproducible from the repository. If your provider relationship changes, the system moves.
05
After launch, if agreed
Your team runs it, watched
We propose a supervised period, typically around ninety days and confirmed in writing once scope is agreed, where your people operate it and we are available but not touching it. It is the only way to find out whether the documentation is true.
06
Ongoing
No proprietary lock-in
Mainstream, well-supported technology throughout. Nothing in the stack that requires us specifically, and nothing you cannot hire for in a decade. Retained work has no minimum term, and thirty days’ notice ends it.
Non-negotiable
Four principles we build to here
- Boring on purpose
- Well-understood technology with a long support horizon beats a faster stack nobody will be able to hire for in a decade.
- Documentation is a deliverable
- Handover is part of the scope, not a favour. The runbook is written so a stranger can run the system without calling us.
- Security by consequence
- Threat modelling starts from what failure would mean physically, not from a generic checklist.
- Data lineage
- Every figure in a regulatory submission traceable to the meter reading it came from.
Where AI actually lands
Four places it earns its cost, and one line we do not cross.
Worth doing
- Load and generation forecasting, where accuracy has direct financial value in settlement.
- Asset condition assessment from inspection data, prioritising work by real risk.
- Outage prediction and restoration sequencing during major weather events.
- Customer contact handling at the volume a storm produces.
Where we stop
Anything with a direct control action on physical infrastructure. That boundary is set by regulation and by engineering practice, and both are correct to hold it.
Evidence
We have no utility reference yet. This page describes how we would approach the work and what we would commit to in writing.
How we deliver it
The services this work draws on.
Enterprise Software
Platforms that hold up under real load, real compliance, and real headcount.
Cybersecurity
Threat modelling, hardening, and the evidence trail an auditor will ask for.
Software Consulting
Architecture review, technical due diligence, and the roadmap that follows from both.
Other sectors we work in
Next step
Tell us what your system has to survive for the next twenty years.
A senior engineer reads every enquiry and replies within one business day with an honest view of what it will take, including what your own team will need to run it without us.
