In short, this project was about enabling Octopus Energy Italy to enter the gas market in early 2025.
It involved many people, both at Kraken, the technology division of the Octopus Energy group, and at Octopus Energy itself.
I was part of the team responsible for the technological integration with the Italian market: in practice, managing the exchange of information with the Italian industry, from the switch-in or transfer of a new customer to the collection of meter data and readings.
There are many processes, but they are publicly documented by the SII (Sistema Informativo Integrato), in case you are a curious reader.
In my specific case, I was responsible for leading the implementation of the system for collecting and processing gas readings.
Context
The goal was to launch a Gas + Electricity offer as quickly as possible.
In practice, this meant making the software platform, Kraken, capable of handling all the processes required to integrate with the Italian gas market.
Beyond that, everything else also had to fit together: bills, customer support, and so on.
There was also, quite rightly, a certain amount of pressure: an energy company's entry into the gas market has a significant economic impact.
The main challenges
The timeline was ambitious, so one of the first challenges was to prioritize the implementation of the most important processes correctly.
In highly complex environments, this is not trivial: in new contexts, you have to make decisions based on partial information, without really knowing how things will behave in production.
Managing gas readings
In my specific case, collecting and processing readings, it is worth remembering that gas readings behave very differently from electricity readings.
To begin with, unlike in the electricity market, smart meter penetration is much lower, and this creates a great deal of unpredictability.
In the electricity market, readings can usually be collected daily, often with a high level of granularity, for example consumption every 15 minutes.
With gas, instead, an actual reading may arrive only a couple of times a year, or not arrive at all.
However, in absolute terms, this does not mean dealing with a small amount of data. On the contrary, the system still has to be efficient. This gave me the opportunity to apply highly performance-oriented techniques from the start, developed on the basis of the problems observed in the electricity market.
Moreover, reading data is particularly critical, because it is the data on which bills are built.
Finally, here too, everything had to be adapted to a context where an operating platform already existed.
Actual consumption, estimates, and recalculated readings
If you have never paid too much attention to your bills, you might ask yourself: "if you do not have the reading, how can you bill me?". The answer is simple: "I estimate it".
The methods and algorithms used to estimate consumption, in general, are regulated. In the case of gas, this is what happens: you start from an existing annual consumption value and from a set of tables, published by Arera, the regulator, which indicate the daily consumption percentage. From there, consumption is estimated for the various days.
One peculiarity of the gas market, however, is that the quality of the data available to you can change very often. For example, you may receive a self-reading directly from the customer.
This is more reliable data than estimates, which also tend to be conservative. This is why, if you do not have a gas smart meter at home, it is worth sending self-readings.
Also, when reliable data is received, the system does not simply store it: all estimated consumption values are recalculated from the data that has been "improved".
For example, suppose I have an estimated reading from the distributor on January 2, which I used to calculate the estimates for January, February, and March. Then an actual reading arrives, therefore a more reliable one, say on January 12. In that case, all the estimates based on the old data are recalculated.
The same applies to self-readings, which are considered more reliable than estimates.
And there is more: whenever possible, when reliable data is received, the system also generates so-called recalculated readings. In practice, if there are estimates between two more reliable readings, more precise estimates can be applied, calculated from an annual consumption value derived from actual consumption.
At this point, it is easy to imagine how the system must be able to manage, accurately, thousands of recalculations and new estimates every day. This data is then used every month to apply adjustments to old bills, when those bills were issued before the new data arrived.
Conclusions
I am very happy to have worked on this project.
Designing and, above all, delivering the system that allows Octopus customers to receive their bills on time, based on data that is as accurate as possible, is not something I take lightly.
It is also a project that gave me great satisfaction: we enabled Octopus to enter the Italian gas market.
Today, in 2026, Octopus has more than 1 million customers, and its impact on the Italian market is tangible. It is a source of pride comparable to what I feel for having launched iliadbusiness, even though in this case I was "only" responsible for managing readings.
My friends have Octopus as their gas supplier, and so do some relatives. Every now and then, someone even asks me a question about their bills.
I do not think many programmers have had the opportunity to work on projects with this kind of impact, and that makes me appreciate this type of experience even more.
No matter how much a person commits and shows they deserve trust, they do not always manage to find the right context, where they can put themselves to the test and achieve great professional satisfaction.
Having had the opportunity to experience professional satisfaction of this kind makes me feel lucky.