Industry
Software engineering for Energy
Energy is being rebuilt around decarbonisation, and the hard part is rarely the interface: it is the market data, the forecasting under genuine uncertainty, the grid constraints that physics imposes, and the fact that this is critical national infrastructure with regulation to match. We build for that reality, honest about where software moves the needle on net zero and where it cannot bend physics or the market.
Why the domain matters
The energy sector is in the middle of the largest restructuring it has seen in a century, and software sits close to the centre of it. The system is shifting from a small number of large, dispatchable thermal plants to a diffuse, weather-driven fleet of wind, solar and storage; from predictable central planning to markets that clear every half hour; and from a one-way grid that pushed power outward to a two-way network where generation, demand and storage all sit on the edges. Every one of those shifts creates demand for software: to forecast, to trade, to optimise assets, to balance a grid that no longer behaves the way it was designed to. The opportunity is real, but so is the risk of building something that looks impressive and ignores the physics, the market rules or the regulator.
It is worth naming the shape of the sector, because software lands very differently at each point. Generation (increasingly renewable), lives on forecasting and asset performance, because you cannot dispatch the wind and every lost megawatt-hour is revenue gone. Energy trading and risk is a data and latency business, clearing positions against half-hourly prices, imbalance risk and volatile fuel and carbon markets. Grid and transmission is a constraint-management and reliability business, governed by network codes and the physical limits of what the wires can carry. And cutting across all of it is decarbonisation: net-zero targets, carbon accounting, and the pressure to squeeze more value and less emission out of every asset. We keep this page to that broad umbrella: the retail meter-to-bill side sits with power and utilities, and the hydrocarbon-specific safety and operations sit with oil and gas.
We are a senior-led team and we operate what we build, so we start from the physical and market reality rather than from a product we would like to sell. The recurring failure mode in energy software is a model or an optimiser that is beautiful in a notebook and wrong against the real dispatch, the real network constraint or the real settlement data, because it treated forecasting uncertainty as noise to be tuned away, or the market rules as a detail. We would rather build the unglamorous data pipeline, the honestly-calibrated forecast and the optimiser that respects the constraints than the dashboard that promises certainty the system cannot deliver. In energy the value is in getting the hard, uncertain middle right, not in the front end on top of it.
The challenges in energy
Forecasting under genuine, irreducible uncertainty
A renewable-heavy system runs on forecasts (of wind, of solar, of demand, of price), and those forecasts are uncertain in ways no amount of engineering removes. The value is not in pretending to a precision the weather will not give you; it is in quantifying the uncertainty honestly and making decisions that are robust to being wrong. Software that hides the error bars, or optimises against a point forecast as if it were fact, produces confident decisions that lose money and destabilise operations when the wind does not blow as predicted.
Market rules and half-hourly data that shape everything
The GB electricity market clears in half-hourly settlement periods, with imbalance pricing, the Balancing Mechanism, and a stack of BSC and network-code rules that are not optional detail. They define what a position is worth and what a trade or a dispatch decision actually means. Software that treats the market as an abstraction, rather than encoding the real settlement and balancing rules, produces numbers that are subtly and expensively wrong. This is where a lot of energy software quietly fails.
Physical constraints that software cannot argue with
The grid can only carry so much power on a given circuit; a battery has a finite state of charge; a wind farm cannot generate above the wind. An optimiser that ignores these constraints produces schedules that look optimal and are physically undeliverable, which is worse than useless because someone trusts them. Much of the real engineering in energy software is encoding the physical limits faithfully so that what the software recommends is something the assets can actually do.
Legacy operational systems and slow-moving standards
Energy runs on a deep stack of existing systems. SCADA and control systems, historians, trading and ETRM platforms, settlement and metering systems: many of them long-lived and mission-critical. New software has to integrate with this estate, not replace it wholesale, and the data standards and market interfaces move slowly and deliberately because reliability matters more than novelty. Any plan that assumes a clean greenfield ignores the infrastructure the operation already depends on every minute.
Decarbonisation targets that must survive contact with data
Net-zero commitments and carbon accounting have moved from the sustainability report into operational decisions, and the credibility problem is real: emissions figures, carbon intensity and offset claims have to be defensible against scrutiny, not marketing numbers. Software that reports carbon has to be honest about scope, methodology and the quality of the underlying data, because greenwashing (accidental or otherwise), is now a reputational and increasingly a regulatory exposure.
Critical national infrastructure raises the security bar
Energy is critical national infrastructure, and systems that touch generation, the grid or market operations sit under the NIS Regulations and the expectations that come with keeping the lights on. The security posture cannot be an afterthought bolted on at the end; the consequences of compromise run from financial to physical to national. This shapes architecture, access and operational practice from the first design decision, not the last.
What we build for energy
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Generation forecasting and asset performance
Forecasting and performance software for generation (especially renewables), that treats uncertainty as a first-class output rather than a rounding error. We build wind and solar forecasting, generation availability and performance monitoring, and the analytics that turn turbine, inverter and SCADA data into an honest picture of how assets are actually performing against expectation, so lost output is spotted and explained rather than quietly absorbed.
Energy trading and risk platforms
Trading, position-keeping and risk tooling built around the real market, half-hourly settlement, imbalance and Balancing Mechanism exposure, and the fuel, power and carbon curves that drive value. We build the data pipelines, position and P&L engines, and risk views that a trading desk can actually act on, encoding the settlement and balancing rules faithfully because a position mispriced against the real market rules is an expensive kind of wrong.
Grid and network operations tooling
Software for the grid and transmission reality: constraint management, network visibility, and the analytics that help operators run a two-way, weather-driven network that was designed for one-way flow. We build tools that respect the physical limits of the network and the governing codes, because a grid tool that recommends something the wires cannot carry is not an optimisation, it is a hazard.
Asset optimisation and flexibility
Optimisation for storage, flexible generation and demand-side assets, dispatching a battery against price and constraint, stacking value across markets and services, and scheduling flexibility where it is worth most. We build optimisers that respect state of charge, cycle limits, network constraints and market rules, so the schedule they produce is one the assets can actually deliver rather than a theoretically optimal fiction.
Carbon accounting and net-zero reporting
Carbon and emissions software that is defensible under scrutiny: measuring carbon intensity, tracking emissions across defined scopes, and reporting against net-zero commitments with honest methodology and clear data provenance. We build these to withstand a hard question about scope and source, because a carbon figure that cannot survive audit is a liability dressed up as a headline.
Market and settlement data platforms
The data backbone the rest depends on: ingesting half-hourly market data, settlement runs, metering and generation feeds reliably, reconciling them, and making them consistent across the systems that were never designed to agree. This is unglamorous, mission-critical plumbing, and in energy it is where a great deal of the real value and the real defects live, so we resource it as core work, not afterthought.
Where we help
A renewable forecast that quantifies its own uncertainty
A generator wants better wind and solar forecasts to reduce imbalance exposure and inform trading. The real work is not a single point forecast but a probabilistic one: ranges and confidence that reflect the genuine uncertainty of the weather, fed into trading and dispatch decisions that are robust to the forecast being wrong. Built honestly, it reduces imbalance cost and surprises; sold as a crystal ball, it produces confident decisions that lose money when the day does not go to plan.
A battery optimiser that respects state of charge and constraints
An operator with grid-scale storage wants to maximise value across price arbitrage and balancing services. We build an optimiser that stacks value across markets while faithfully respecting state of charge, round-trip efficiency, cycle limits and network constraints, so the schedule it produces is physically deliverable and does not quietly degrade the asset. The measurable win is more value per cycle; the trap we avoid is a schedule that is optimal on paper and impossible in the cell.
A position and risk view built on the real settlement rules
A trading function needs positions, P&L and imbalance risk that reflect the actual half-hourly market rather than a simplified model. We build the data pipeline and the position engine to encode settlement periods, imbalance pricing and Balancing Mechanism exposure faithfully, so the desk is acting on numbers that match the market it settles against. In trading, a position that is subtly wrong against the real rules is worse than no position at all.
Carbon reporting that survives an auditor’s hard question
An energy business needs to report carbon intensity and progress against net-zero commitments in a way that withstands scrutiny from auditors, investors and regulators. We build the measurement and reporting with explicit scope boundaries, transparent methodology and traceable data provenance, so every headline number can be defended down to its source. Done honestly, it protects the business; done as marketing, it is a greenwashing exposure waiting to be found.
How we build for energy
We start from the physics and the market rules, not the screens. Before designing anything we want to understand the real dispatch, the real network constraints, the settlement periods that define value, and where the genuine uncertainty in the system lives. In energy the constraint is almost never the interface: it is whether the model, the optimiser and the data underneath them are honest about the physical and market reality they operate in. We design for that reality, not for a dashboard that looks decisive.
We are blunt about what software can and cannot change. It can quantify uncertainty, encode the market rules faithfully, spot lost generation and squeeze more value out of an asset within its real limits. It cannot make the wind blow, bend a network constraint, or turn an irreducibly uncertain forecast into certainty. We would rather tell you early where the value genuinely is (and where an idea just dresses up a guess as a decision), than build an optimiser that looks confident and is quietly wrong against the real system.
We treat forecasting uncertainty and market-rule fidelity as the core of the work, resourced accordingly. A forecast without honest error bars, or an optimiser that ignores a physical or settlement constraint, is not a smaller version of the right thing: it is the wrong thing, and it fails expensively in production. We build the probabilistic forecast, the faithful settlement model and the constraint-respecting optimiser from the start, because in this sector the difference between roughly right and confidently wrong is measured in money and in stability.
Because we operate what we build, the people designing a dispatch optimiser or a settlement pipeline are the ones who get called when a schedule cannot be delivered or a position does not reconcile against the settlement run. That concentrates the mind on the failure modes that actually matter in energy (undeliverable schedules, mispriced positions, forecasts trusted past their uncertainty), and it keeps us honest about trade-offs up front rather than discovering them when the system is live and the market has moved.
Regulation and compliance
Ofgem is the economic regulator for the GB energy market, and its rules reach into software wherever a system touches licensed activity, market participation or the codes that govern how the market works. The Balancing and Settlement Code, the network codes, and the market interfaces are not optional context: they define what a position, a settlement or a dispatch decision actually is, and software that gets them wrong produces numbers that are legally and financially wrong, not merely imperfect.
Wholesale market conduct sits under REMIT, which prohibits market abuse and insider dealing in energy and carries real obligations around transaction reporting and transparency. Where our software supports trading or market participation, it has to be built with these obligations understood. The audit trail, the reporting and the controls are design inputs, not features to add if there is time, because market-abuse exposure is a serious matter for a licensed participant.
Decarbonisation brings its own layer of obligation and scrutiny: carbon reporting standards, emissions accounting methodologies, and the growing expectation that net-zero claims are defensible rather than promotional. We build carbon and emissions software to be transparent about scope, method and data quality, because the regulatory and reputational cost of a figure that cannot be defended is rising, and accidental greenwashing is still greenwashing.
We build systems that meet these obligations, but we are engineers, not your regulatory or legal advisers. The rules around market participation, REMIT, the industry codes and carbon reporting carry real weight, and sign-off on them rests with your own regulatory, compliance and legal functions. Our job is to build software that encodes and evidences what those obligations require, and to work alongside the people accountable for them rather than pretending to replace them.
Integration
The market and settlement systems are the gravitational centre for anything commercial. Half-hourly market data, settlement runs, the Balancing Mechanism and the elexon/BSC interfaces are where value is defined, so trading, forecasting and optimisation software has to consume and reconcile this data reliably. These are deliberate, slow-moving interfaces built for reliability, and we integrate with them faithfully rather than pretending the market is a simpler abstraction than it is.
Operational technology is the other side of the problem. SCADA and control systems, historians and asset-monitoring platforms hold the physical truth of what generation and the network are actually doing, and much of the value in generation and grid software comes from turning that operational data into decisions. We integrate with the OT estate carefully and with the appropriate security boundary, because these systems are mission-critical and the line between the corporate and control-system worlds is one to respect, not blur.
Trading and risk platforms, ETRM systems, and fuel, power and carbon market data feeds all have to plug into the commercial flows. Positions, curves and P&L have to reconcile across these systems and against the settlement data, so we treat that reconciliation as first-class engineering, because in trading a number that does not tie out across the stack is the fastest way to lose the desk’s trust in the software.
Weather and forecast data, asset telemetry, and the growing world of distributed and flexible assets add further feeds that rarely agree in format or timing. The recurring engineering problem across all of it is the same: keeping data consistent, timely and reconciled as it crosses market systems, OT, trading platforms and external feeds that were never designed to agree with one another. We treat that reconciliation as core work, because in energy the data backbone is where reliability is won or lost.
Security and critical national infrastructure
Energy is critical national infrastructure, and systems that touch generation, the grid or market operations fall under the NIS Regulations and the heightened expectations that come with keeping the lights on. This is not a compliance checkbox: the consequences of compromise run from financial loss through market disruption to physical impact on the network, so we build with the security posture as a first design decision rather than a report handed over at the end.
The boundary between operational technology and corporate IT deserves particular respect. SCADA and control systems were often designed for isolated, trusted environments, and connecting them to the wider world for the analytics and optimisation the transition demands has to be done with deliberate segmentation, controlled data flows and a clear understanding of what must never be reachable. We treat that OT boundary as a security architecture problem in its own right, not an integration convenience.
Market and trading systems are a direct financial and market-integrity surface. Position data, curves and trading decisions are sensitive and valuable, and the same systems carry REMIT and market-abuse considerations, so we build them with strong authentication, scoped access, and audit trails that make it possible to reconstruct exactly who did what and when, because in a market that clears in half-hourly periods, the ability to prove what happened is part of the deliverable.
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 or a regulator would need, and design for resilience against the reality that critical infrastructure is a target. Keeping the ability to reconstruct exactly what happened (to a schedule, a position or a control action), is part of what we build, not something found missing after an incident.
What changes
Decisions that are robust to the uncertainty they face
Because we treat forecasting uncertainty as a first-class output rather than a number to tune away, the trading and dispatch decisions the software supports are robust to the forecast being wrong, reducing imbalance cost and nasty surprises instead of producing confident decisions that lose money when the weather does not cooperate.
Schedules and positions that survive contact with reality
By encoding physical constraints and the real market rules faithfully, the optimisers and position engines we build produce schedules the assets can actually deliver and numbers that reconcile against the settlement run, rather than theoretically optimal fictions that fail the moment someone tries to act on them.
Carbon and performance figures you can defend
Because we build carbon accounting and asset performance to be transparent about scope, method and data provenance, the figures your business reports withstand scrutiny from auditors, investors and regulators, protecting you rather than exposing you to a greenwashing or performance-claim challenge you cannot answer.
What we build for energy
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 energy?
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 energy choose us
We build for the physics and the market, not the pitch deck
The reason a lot of energy software fails is that it treats the physical constraints and the market rules as detail and the dashboard as the product. We start from the real dispatch, the real network limits and the real settlement rules, because a model that is beautiful in a notebook and wrong against the system has delivered nothing.
We are honest about uncertainty
A renewable-heavy system runs on forecasts that are irreducibly uncertain. We quantify that uncertainty honestly and build decisions that are robust to being wrong, rather than selling a point forecast as certainty, because in energy, confidence the system cannot support is exactly how software loses money.
We treat the data backbone and integration as the hard part
Half-hourly market data, settlement, SCADA and trading systems are where energy projects are won or lost. We resource the ingestion, reconciliation and faithful market-rule encoding from day one instead of discovering it late, which is what separates software the desk and the control room trust from software they quietly work around.
We operate what we build
The people who design a dispatch optimiser or a settlement pipeline are the ones paged when a schedule cannot be delivered or a position does not reconcile. That keeps us focused on the failure modes that matter in energy (undeliverable schedules, mispriced positions, forecasts trusted past their limits), and honest about trade-offs up front, not in production on your behalf.
Related sectors
Adjacent sectors we also know.
Common questions
Can you build forecasting for wind, solar and demand?
Yes, and we build it to be honest about uncertainty rather than to promise a precision the weather will not give you. The value in a renewable-heavy system is not a single point forecast but a probabilistic one: ranges and confidence that reflect genuine uncertainty, fed into trading and dispatch decisions that are robust to the forecast being wrong. We build the data pipelines and the models to reduce imbalance exposure and surprises; what we will not do is sell a forecast as a crystal ball, because a confident forecast trusted past its limits loses money when the day does not go to plan.
Do you understand the GB market rules, settlement, imbalance, the Balancing Mechanism?
Yes, and we treat them as core to the work rather than an abstraction to simplify away. The market clears in half-hourly settlement periods, with imbalance pricing, the Balancing Mechanism and the BSC and network codes defining what a position or a dispatch decision is actually worth. Software that treats the market as a simplified model produces numbers that are subtly and expensively wrong, so we encode the real settlement and balancing rules faithfully and reconcile against the settlement runs. To be clear on the boundary: we are engineers, not your regulatory advisers, so market-conduct and REMIT sign-off rests with your compliance function, and we build to work alongside it.
Can software actually help us hit net zero, or is carbon reporting just marketing?
Software helps when it removes real emissions or makes decisions genuinely lower-carbon and reports them defensibly, and it becomes a liability when it dresses up marketing numbers as measurement. We build carbon accounting and net-zero reporting to be transparent about scope, methodology and data provenance, so every figure can survive an auditor’s or a regulator’s hard question. We also build the asset optimisation and forecasting that squeeze more value and less emission out of the real system. Where an idea is greenwashing (accidental or otherwise), we will say so, because a carbon figure that cannot be defended is an exposure, not an achievement.
How do you handle security given energy is critical national infrastructure?
As a first design decision, not a report at handover. Systems touching generation, the grid or market operations fall under the NIS Regulations and the heightened expectations of critical national infrastructure, where the consequences of compromise run from financial to physical. We build with segmentation between operational technology and corporate IT, controlled data flows across that boundary, scoped access, strong authentication and audit trails that let you reconstruct exactly what happened to a schedule, a position or a control action. Because we operate what we build, that resilience and instrumentation is part of the deliverable, not something discovered missing after an incident.
Can you integrate with our SCADA, historians, trading and settlement systems?
Yes, and we plan for it from the start because the energy estate is deep and mission-critical. SCADA and historians hold the physical truth of what the assets and network are doing; trading and ETRM platforms and the settlement systems hold the commercial truth; and these were never designed to agree with one another. We integrate with the OT estate carefully and with the right security boundary, consume half-hourly market and settlement data faithfully, and treat reconciliation across the whole stack as first-class engineering, because in energy a number that does not tie out across systems is the fastest way to lose the control room’s or the desk’s trust.
Building for energy?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if energy 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.