Sleepless nights, costly decisions, and that first line of working code.
It all started with two rather painful experiences when we tried to develop a machine learning (ML) solution through outsourcing. After six months of work, several thousand euros spent, and not a single line of working code, we came to a simple conclusion: we’d have to write the code ourselves.
Our first ML model recipe:
- One burnt-out laptop
- One broken server
- Countless sleepless nights and more coffee than we’d like to admit
- And, luckily, a few more experienced colleagues in the ML field
Sleep had become such a luxury that I even stopped wearing my Garmin watch - just so it wouldn’t remind me to rest. Ironically, the knowledge I once gained from free online courses on building e-commerce websites turned out to be surprisingly useful. Structuring code, managing server resources, handling APIs - it all came back to me and gave me a significant advantage when working with ML systems.
The first mistake: oversimplifying the task. When we started this project, it seemed simple enough: we wanted to make building heating systems smarter. The goal was to prevent situations where heating systems overheated buildings without considering external factors such as temperature, wind, and sunlight.
Our vision was to create an ML system that would dynamically adjust heating schedules based on these factors and the specific characteristics of each building. The desired outcome? To save 13-15% of energy without compromising office comfort.
It seemed achievable - so we decided there was no need to hire an in-house developer and instead outsourced the work. A classic mistake. We significantly underestimated the complexity of the task.
The second mistake: underestimating the right mix of skills. We assumed the project would require about 30% expertise in building automation and 70% in machine learning development. In reality, it turned out to be exactly the opposite. The nuances of building behavior, the thermal properties and heat loss characteristics of different materials, and the way systems respond to external changes - all of it proved to be far more significant than we initially thought.
The third mistake: not reading the fine print. The most painful part was realizing too late that our contract included a clause stating that all developed software would belong to the outsourcing provider. An expensive mistake, yes, but also a hidden blessing. This experience pushed us to develop our own skills and build everything in-house.
We turned lemons into lemonade. Now, not only do I have a much deeper understanding of machine learning, but several of our developers have also become skilled ML engineers.
Apologies and “Iron Man” moments. I owe an apology to our project manager, who was utterly confused as to why the building had “made a decision on its own.” Inspiration struck me around midnight, and I simply couldn’t resist the urge to run the algorithm in live mode. As my fellow engineer Tony Stark once said, “Sometimes you’ve got to run before you can walk.”
Where are we now?
We’ve built a solid foundation - working code, knowledge that stays within the company, and the ability to keep evolving. The best part? We’ve achieved our energy-saving targets. At least on paper. Now all that’s left is to wait for the heating season. Or, perhaps for the first time ever, I quietly hope for a cool summer.
