Energy
Software engineering for Power & Utilities
The distance from a meter reading to a correct bill is where utilities software lives and dies. Smart metering, the DCC, half-hourly settlement, switching and meter-to-cash are a web of industry data flows and Ofgem rules where a small error becomes a large, visible, regulated failure at scale. We build for that reality (the unglamorous data accuracy that keeps bills right and customers whole), not the app on top of it.
Why the domain matters
Power and utilities is defined by a deceptively simple-sounding job done at enormous scale under heavy regulation: measure what each of millions of customers used, and bill them correctly. Almost none of the complexity is visible from the outside, and almost all of it lives in the space between a meter and a bill: smart-meter data flowing through the national infrastructure, half-hourly consumption reconciled and settled between suppliers and networks, switching moving customers between suppliers, and a meter-to-cash process that has to be right the first time across a vast population. When it works, nobody notices. When a data flow breaks or a settlement figure is wrong, the failure is large, public and regulated, because it lands on customers’ bills and on the regulator’s desk.
The sector splits along a line worth naming, because software lands very differently on each side. On the network side sit the distribution network operators moving toward distribution system operator roles: running the physical low-voltage and medium-voltage networks, managing outages and connections, and increasingly coordinating distributed generation, storage and flexibility at the grid edge. On the retail and supply side sit the suppliers and the meter-to-cash machinery: smart metering and the DCC, billing, settlement, switching, and customer service. Cutting across both is a dense web of industry data flows and central systems that participants must interoperate with correctly. We keep this page to that meter-to-bill and network-operations reality; the broader sector and generation-side markets sit with energy, and hydrocarbon operations with oil and gas.
We are a senior-led team and we operate what we build, so we start from the data flows and the regulatory reality rather than from a product we would like to sell. The recurring failure mode in utilities software is a clean-looking front end sitting on top of meter-to-cash data that is quietly wrong: estimated reads treated as actual, settlement that does not reconcile, a switch that half-completes and leaves a customer billed by two suppliers or none. At scale, small data errors become thousands of wrong bills, complaints and a regulatory problem. We would rather build the unglamorous accuracy. The reconciliation, the honest handling of estimated versus actual, the data flows that stay in sync, than the customer app that looks good over data nobody can trust.
The challenges in power & utilities
Meter-to-cash accuracy at unforgiving scale
The path from a meter reading to a correct bill runs through data acquisition, validation, settlement and billing, across millions of customers, and it has to be right. At this scale a small systematic error is not a minor bug: it is thousands of wrong bills, a wave of complaints, and a regulatory exposure. The value in utilities software is overwhelmingly in getting this pipeline accurate and reconciled, because a beautiful customer experience laid over meter-to-cash data that is quietly wrong is a liability, not a product.
Smart metering and the DCC’s real complexity
Smart metering runs through national infrastructure (SMETS meters communicating via the Data Communications Company), and integrating with it is a substantial, exacting piece of engineering, not a simple API call. The interfaces, the enrolment and adoption processes, the message flows and the operational realities of a national estate of meters are genuinely complex, and software that underestimates the DCC integration ships late and half-working. This is one of the places where utilities projects most often come unstuck.
Half-hourly settlement that must reconcile
Electricity is settled in half-hourly periods between suppliers and networks, and market-wide half-hourly settlement raises the volume and importance of that data enormously. The consumption figures have to reconcile (across meter data, settlement systems and billing), and discrepancies are not cosmetic; they translate into money moving incorrectly between parties and, ultimately, wrong outcomes for customers. Software that treats settlement as an abstraction rather than encoding the real reconciliation produces numbers that are subtly and expensively wrong.
Switching and industry data flows between participants
Customers move between suppliers, and that switch is a choreography of industry data flows between the losing supplier, the gaining supplier, the network and central systems, with meter details, readings and responsibilities all having to hand over cleanly. A switch that half-completes leaves a customer billed by two suppliers or none, a classic and damaging failure. Getting these market-wide data flows right, faithfully and resiliently, is core to any supplier-side software rather than an integration detail.
Network operations and the DNO-to-DSO shift
On the network side, operators run physical distribution networks, managing outages, connections and now a growing population of distributed generation, storage and flexibility at the grid edge as they move toward system-operator roles. The network was built for one-way flow and now has to manage two-way, active edges, which changes what the operational software has to do: outage management, connection processing and flexibility coordination on a network that no longer behaves the way it was designed to.
Ofgem regulation woven through the software
Ofgem regulates the market closely, and its rules reach directly into supplier and network software, from billing accuracy and back-billing limits to switching performance, vulnerable-customer obligations and the industry codes that govern data flows and settlement. These are not compliance paperwork bolted on at the end; they shape what the software must do, evidence and get right, and a failure here is a regulatory matter for your client, not merely a defect.
What we build for power & utilities
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Smart metering and DCC integration
Software that integrates with smart metering and the Data Communications Company as the substantial engineering it is, handling the SMETS estate, the DCC message flows, enrolment and adoption, and the operational reality of communicating with millions of meters. We resource this as a first-class problem rather than a simple API integration, because underestimating the DCC is one of the most reliable ways a utilities project ships late and half-working.
Billing and meter-to-cash platforms
Billing and meter-to-cash software built around accuracy at scale, data acquisition and validation, honest handling of estimated versus actual reads, tariff and calculation logic, and billing that reconciles against consumption. We treat the accuracy of this pipeline as the whole game, because at utility scale a systematic billing error is thousands of wrong bills and a regulatory problem, and no amount of front-end polish makes wrong bills acceptable.
Settlement and consumption data platforms
The data backbone for half-hourly settlement: ingesting large volumes of meter and consumption data, validating and reconciling it, and making it consistent across settlement, billing and reporting. This is heavy, mission-critical data engineering where correctness and reconciliation matter far more than novelty, and where a great deal of the real value and the real defects in utilities software live.
Switching and industry data-flow handling
Software that handles customer switching and the industry data flows between suppliers, networks and central systems faithfully and resiliently, meter details, readings and responsibilities handed over cleanly so switches complete rather than half-completing. We build these to cope with the messiness and edge cases of real market data flows, because a switch that leaves a customer billed twice or not at all is a classic, damaging and entirely avoidable failure.
Outage and network operations tooling
Operational software for distribution network operators moving toward system-operator roles: outage management, connection processing, network visibility, and the coordination of distributed generation, storage and flexibility at the grid edge. We build these for the reality of a network designed for one-way flow now managing active, two-way edges, respecting the physical and operational limits the network actually imposes.
Customer portals and service tooling
Self-service portals and service tooling that take load off contact centres (customers viewing usage, understanding bills, managing payments and raising queries), built on top of meter-to-cash data that is actually correct. We are clear that a customer portal is only as good as the billing and metering data behind it, so we build the front end deliberately over accurate data, not as a distraction from a pipeline that has not been made right.
Where we help
DCC integration that works against the real estate
A supplier needs to communicate with its smart-meter estate through the DCC (reads, commands, enrolment and adoption), reliably and at scale. The real work is the exacting engineering of the DCC interfaces and message flows and the operational reality of a national meter estate, not a simple API call. Built properly, it gives the supplier trustworthy smart-meter data to bill and serve on; underestimated, it becomes the reason the wider programme ships late and the reads cannot be relied on.
A billing pipeline that is right the first time
A supplier needs meter reads turned into correct bills across a large customer base, handling estimated and actual reads honestly and reconciling against consumption. We build the acquisition, validation, calculation and reconciliation with accuracy as the whole objective, because at this scale a systematic error is thousands of wrong bills, a complaint wave and an Ofgem problem. The measurable win is bills that are right and defensible; the trap we avoid is polishing the customer app while the meter-to-cash data underneath it is quietly wrong.
A switch that completes cleanly instead of half-completing
A supplier gaining and losing customers needs the industry data flows around switching handled so that meter details, readings and billing responsibility hand over cleanly. We build these flows to be resilient to the edge cases and messiness of real market data, so switches complete rather than leaving a customer billed by two suppliers or none. In a regulated market where switching performance is watched and a botched switch is a visible customer harm, getting this choreography right is core, not incidental.
Outage management for a two-way grid
A distribution operator needs to manage outages and connections on a network that now carries distributed generation, storage and flexibility at its edges. We build outage and network operational tooling that reflects a network designed for one-way flow now managing active, two-way edges (surfacing outages clearly, supporting restoration and coordinating the growing grid-edge population), respecting the physical and operational limits the network actually imposes rather than assuming the simpler network it used to be.
How we build for power and utilities
We start from the meter-to-cash data flows and the regulatory reality, not the screens. Before designing anything we want to understand how reads actually arrive, where estimated stands in for actual, how settlement and switching flows behave, and which Ofgem obligations reach into the system. In utilities the constraint is almost never the interface (it is whether the data pipeline underneath is accurate, reconciled and resilient), so we design for that unglamorous accuracy rather than for a dashboard that looks decisive over data nobody can trust.
We are blunt about where the value in utilities software really is. It is overwhelmingly in getting the meter-to-cash pipeline right at scale (accurate reads, honest handling of estimates, settlement that reconciles, switches that complete), because at this scale a small systematic error becomes thousands of wrong bills and a regulatory event. A beautiful customer experience over data that is quietly wrong is a liability, and we would rather tell you that early than build a polished front end on a pipeline that has not been made trustworthy.
We treat DCC integration, settlement reconciliation and the industry data flows as the core of the work, resourced accordingly. Smart-metering integration through the DCC, half-hourly settlement reconciliation and the switching data flows between participants are exacting, and underestimating them is the most reliable way a utilities project ships late and half-working. We plan for their real complexity, their edge cases and their operational realities from the start, rather than discovering them late when the front end is done and the data will not flow.
Because we operate what we build, the people designing a billing pipeline or a switching flow are the ones who understand that a systematic billing error or a half-completed switch is a wave of complaints and a regulatory problem, not a support ticket. That concentrates the mind on the failure modes that actually matter in utilities, wrong bills at scale, settlement that does not reconcile, switches that strand a customer, and it keeps us honest about trade-offs up front rather than discovering them when the bills go out wrong.
Regulation and compliance
Ofgem regulates the retail energy market closely, and its rules reach directly into supplier and network software. Billing accuracy and back-billing protections, switching performance, and the industry codes governing data flows and settlement are not optional context: they define what the software must do and get right, and a failure here lands on customers and on the regulator rather than staying a private defect. We build with these obligations as design inputs, because in this sector the regulatory rules shape the software’s core behaviour.
Obligations toward customers, and vulnerable customers in particular, carry real weight: around fair treatment, accurate billing, complaint handling and support for those in difficulty. Where our software touches these, it has to capture and support what the obligations require, because getting them wrong is not only a regulatory exposure but a genuine harm to people who depend on an essential service. We build these considerations in deliberately rather than treating them as edge cases.
The industry codes and central systems that govern metering, settlement and switching define how participants must interoperate, and conformance to them is a condition of operating in the market, not a nicety. Software that participates in these flows has to adhere to the relevant codes and interfaces faithfully, because a participant that does not conform correctly creates errors that ripple across the market and back onto customers.
We build systems that meet these obligations, but we are engineers, not your regulatory or legal advisers. The rules around billing, back-billing, switching, vulnerable customers and the industry codes carry real legal and regulatory weight, and sign-off on them rests with your own regulatory, compliance and legal functions. Our job is to build software that encodes, evidences and supports what those obligations require, and to work alongside the people accountable for them rather than pretending to replace them.
Integration
The smart-metering infrastructure is the gravitational centre for supplier-side software. Communicating with the SMETS estate through the Data Communications Company (reads, commands, enrolment and adoption), is substantial, exacting engineering, and the DCC interfaces and message flows are genuinely complex rather than a simple API. We integrate with this national infrastructure as the first-class problem it is, because trustworthy smart-meter data is the foundation everything downstream in billing and settlement depends on.
Settlement, billing and the industry central systems are the other side of the integration problem. Half-hourly consumption data has to move and reconcile between meter data, settlement and billing; switching flows have to hand customers cleanly between participants; and the central industry systems define how all of it interoperates. We treat this reconciliation and conformance as first-class engineering, because in utilities a figure that does not tie out across metering, settlement and billing is money moving wrongly and bills coming out wrong.
On the network side, operational integration reaches into the systems that run the physical network: asset and network management, outage and connection systems, and the growing world of distributed generation, storage and flexibility at the grid edge. As operators move toward system-operator roles, coordinating those active edges means integrating data from a network that now behaves very differently from the one-way system its older systems were built for.
The recurring engineering problem across all of it is the same: keeping data accurate, timely and reconciled as it crosses smart-metering infrastructure, settlement, billing, switching flows and network systems that were never designed to agree, at a scale where small inconsistencies become large, visible failures. We resource that reconciliation as core work, because in utilities the data backbone is where correct bills and a functioning market participation are won or lost.
Security and data protection
Power and utilities is critical national infrastructure, and systems that touch the network, metering or market operations sit under the NIS Regulations and the heightened expectations that come with keeping an essential service running. This is not a compliance checkbox, disruption to metering, settlement or network operations affects millions of people, so we build with the security posture as a first design decision rather than a report handed over at the end.
The customer and consumption data in these systems is both extensive and sensitive: personal details, payment information, and granular smart-meter consumption data that reveals a great deal about how people live. Smart-meter data in particular deserves careful, privacy-conscious handling: scoped access, clear purpose limitation, and deliberate thought about who and what ever needs to see fine-grained consumption, because it is exactly the kind of data flow that becomes an incident or a privacy failure when added without care.
Billing, payment and switching flows are a direct financial and integrity surface. Payment handling, the movement of money implied by settlement, and the correctness of switches all have to be protected with strong authentication, scoped access and reconciliation that makes discrepancies visible rather than silent, because in utilities a payment or settlement error that goes quietly astray, or a switching flow that is manipulated, does real financial and customer harm at scale.
Because we operate what we build, security here is not a document produced at handover. We instrument for the access patterns and anomalies that indicate a problem, keep the audit trail an investigation, a regulator or a data-subject request would need, and treat the ability to reconstruct exactly what happened to a customer’s data, bill or switch as part of the deliverable. In critical infrastructure serving millions, detecting and reconstructing an incident is something you build in, not something you find missing afterwards.
What changes
Bills that are right at scale
Because we treat meter-to-cash accuracy as the whole game rather than a detail under the customer app, the billing pipeline produces bills that are correct and defensible across a large customer base, avoiding the thousands of wrong bills, complaint waves and regulatory exposure that a small systematic error becomes at utility scale.
Metering, settlement and switching that reconcile
By resourcing DCC integration, half-hourly settlement reconciliation and the switching data flows as the exacting engineering they are, the data ties out across metering, settlement and billing and switches complete cleanly, rather than leaving figures that do not reconcile or customers stranded between suppliers.
Regulatory obligations met in the data, not just the policy
Because we build Ofgem obligations (billing accuracy, back-billing, switching performance, vulnerable-customer support and code conformance), in as design inputs, the software captures and evidences what the rules require, so compliance lives in the data trail rather than in a policy the system quietly fails to honour.
What we build for power & utilities
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 power & utilities?
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 power & utilities choose us
We build for the meter-to-cash reality nobody sees
Almost all the complexity in utilities lives between a meter and a bill, and almost none of it is visible from the outside. We start from that data pipeline (reads, settlement, switching, reconciliation), because a polished customer app over meter-to-cash data that is quietly wrong is a liability, and getting the invisible middle right is the whole game.
We treat DCC and industry data flows as the hard part they are
Smart-metering integration through the DCC, half-hourly settlement and the switching flows between participants are exacting, and underestimating them is the most reliable way a utilities project ships late and half-working. We resource them from day one instead of discovering their real complexity late.
We are honest about accuracy over polish
At utility scale a small systematic error becomes thousands of wrong bills and a regulatory event, so we will tell you plainly that the value is in the accuracy of the pipeline, not the shine on the front end, and we would rather make the meter-to-cash data trustworthy than build a customer experience on data that cannot be relied on.
We operate what we build
The people who design a billing pipeline or a switching flow are the ones who understand that a systematic error or a half-completed switch is a complaint wave and an Ofgem problem, not a support ticket. That keeps us focused on the failure modes that matter in utilities and honest about trade-offs up front, not when the bills go out wrong.
Related sectors
Part of Energy. Adjacent sectors we also know.
Common questions
Can you integrate with smart metering and the DCC?
Yes, and we treat it as the substantial engineering it is rather than a simple API integration. Communicating with the SMETS estate through the Data Communications Company (reads, commands, enrolment and adoption), involves genuinely complex interfaces, message flows and operational realities across a national meter estate, and underestimating it is one of the most reliable ways a utilities project ships late and half-working. We resource DCC integration as a first-class problem from the start, because trustworthy smart-meter data is the foundation everything downstream in billing and settlement depends on, and there is no shortcut to getting it right.
How do you make sure billing is accurate at scale?
By treating meter-to-cash accuracy as the whole game rather than a detail under the customer app. We build the acquisition, validation, calculation and reconciliation with correctness as the objective, handle estimated versus actual reads honestly, and reconcile billing against consumption, because at utility scale a small systematic error is not a minor bug, it is thousands of wrong bills, a complaint wave and an Ofgem problem. We are blunt that a beautiful front end over meter-to-cash data that is quietly wrong is a liability, so we make the pipeline trustworthy first and build the customer experience deliberately on top of accurate data.
Can you handle customer switching and the industry data flows?
Yes, and we build them to be resilient to the messiness of real market data. A switch is a choreography of industry data flows between the losing supplier, the gaining supplier, the network and central systems, with meter details, readings and billing responsibility all having to hand over cleanly. We build these flows to cope with the edge cases so switches complete rather than half-completing and leaving a customer billed by two suppliers or none: a classic, damaging and avoidable failure. In a regulated market where switching performance is watched, getting this choreography right and conforming to the industry codes is core, not an integration detail.
What can you build for distribution network operators?
On the network side we build operational software for the reality of distribution operators moving toward system-operator roles: outage management, connection processing, network visibility, and the coordination of distributed generation, storage and flexibility at the grid edge. The network was built for one-way flow and now has to manage active, two-way edges, which changes what the software must do. We build it respecting the physical and operational limits the network actually imposes, rather than assuming the simpler, one-way system its older tooling was designed for, because a network tool that ignores those limits is a hazard, not an optimisation.
How do you handle Ofgem regulation and customer data protection?
As design inputs that shape the software’s core behaviour, not paperwork bolted on at the end. Ofgem’s rules on billing accuracy, back-billing, switching performance, vulnerable-customer support and the industry codes reach directly into what the software must do and evidence, so we build them in deliberately. On data protection, utilities hold extensive and sensitive information: personal details, payment data, and granular smart-meter consumption that reveals how people live, so we handle it with scoped access, purpose limitation and privacy-conscious design, smart-meter data especially. To be clear on the boundary: we are engineers, not your regulatory or legal advisers, so sign-off on these obligations rests with your compliance and legal functions, and we build to work alongside them.
Building for power & utilities?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if power & utilities 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.