The project was about building a new core product in Kraken to manage readings across different markets and support international expansion.
Kraken is an all-in-one operating system for utilities. It manages and automates every operational aspect of an energy company.
Although Kraken started as a technology from the Octopus Energy group, it is now sold to dozens of other operators in several countries around the world. As you can see from the website, this includes names such as Plenitude, Origin, EDF, Tokyo Gas, and EON.
Context
The initial situation, when it came to managing readings, was quite fragmented. The software in use was high quality, but often "repeated" across different markets.
Many shared features had in fact been written, and continued to be maintained, in different parts of the system: for example in two different countries.
This is understandable, because readings management is closely tied to the local market: each country has its own formats and processes.
However, many needs remain similar: querying the system, performing correction actions, visualizing consumption charts, applying validations to incoming readings, and so on. These are all common requirements.
So the decision was made to create a core product and a new team. The goal was to build a central dashboard that:
- centralized all common functionality
- remained extensible and customizable by local teams
This would give us the best of both worlds: on one side, we would stop developing and maintaining the same features multiple times, using a single core product instead. Reliability would benefit too: reusing a battle-tested core product, already used in many countries, is more stable than rewriting a new feature from scratch. On the other side, we would still be able to customize the dashboard according to each country's specific needs.
We then kicked off this product and, in my new dedicated Tech Lead role, started building an international team from scratch and laying the system's technical foundations.
Challenges
As mentioned above, we did not want to take away local teams' ability to customize the dashboard.
Each country has its own specific needs, so it is right for local teams to be able to make ad hoc customizations: custom actions, the format and properties of the data shown, groupings, country-specific filters, and more.
On top of that, the system handles a very large amount of data. For example: in Italy, electricity readings can have 15-minute granularity, which means 96 readings per day. In Australia, they can even arrive every 5 minutes, which means 288 readings per day.
Across 1,000,000 supply points of that kind, this would mean:
- 96,000,000 readings per day in the Italian case
- 288,000,000 readings per day in the Australian case
Kraken has processing and storage systems that can handle this amount of data very well. However, as you can imagine, enabling dynamic filters, groupings, and charts on such a large amount of data is not trivial.
The dashboard also cannot only cover retail market needs: it must cover B2B needs as well. This introduces several difficulties, especially because in the B2B energy market you start thinking in terms of large groups of supply points, not just individual ones. As a result, the needs and goals also change.
Another important challenge was organizational: I had to create an international team from scratch.
It was not the first time I had found myself hiring and managing a new team (I had already done it at iliad, with iliadbusiness), but that still does not make things easy: interviewing, mentoring, introducing new people into a complex ecosystem, and making them productive remains a hard challenge.
Moreover, all of this sometimes has to happen while coordinating across unfavorable time zones, since the team is globally distributed. For European countries there is not much friction. The so-called "APAC timezone", however, is more complex.
For example, with Australia, from Italy, we are talking about an 8-hour difference in the best periods and a 10-hour difference in the worst ones. The overlap in working hours is practically nonexistent, and that requires adaptability. Honestly, I do not think it is for everyone.
Results
I have had great satisfaction from this project.
As of today (2026), the team is distributed across the UK, Germany, Italy, and Australia.
Our product is used globally, in more than 9 different countries. As for the customers using it, I have honestly lost count.
The feedback from users has been excellent, and we continue to run user interviews regularly to stay in touch with them and keep them happy.
From a technical point of view, we have also reached a point where other developers use our product almost as if it were a real framework: they enable it for new customers, customize it, and extend it without the team even noticing, because they are fully autonomous.
Our efforts to provide easy-to-use APIs and clear technical documentation have paid off.
If we look at reliability, the numbers are very good here too. The only real concerns come from the cutting-edge new features we continue to introduce, but we still release them gradually, so they can reach full stability before complete adoption.