Modern buildings don’t always need new infrastructure to become smarter. Sometimes, they need a better way to connect what’s already there. That idea sits at the heart of Nobody Engineering, which helps building owners and service providers access existing automation systems without replacing functional equipment or tying themselves to a single software vendor.
In this interview with Eqvista, Ville Ilkkala, CPO of Nobody Engineering, shares the unconventional journey that took him from construction and journalism to building technology and explains how a difficult pilot reshaped the company’s direction. When an effort to connect around 200 buildings reached just three, the team discovered that its most important opportunity wasn’t another application, but the missing connectivity that would allow modern software to work with legacy systems.
Ville, could you start by telling us a little about your background and what led you to start Nobody Engineering?
My background isn’t exactly conventional. I trained as an excavator driver, but left construction after a year and a half because I couldn’t stand the atmosphere on construction sites. I moved to London to become a street magician, which didn’t work out, then studied journalism and worked for small newspapers. After that, I studied media and special effects, which led to an internship at Nokia Research Center, interaction design, and eventually games and health technology.
The common thread was always an interest in new technology and how it changes society. I started the company in 2018 with the idea of developing a software platform built around semantically linked data, making software development easier. We explored applications in industrial supply chains, logistics and energy before ending up in buildings. Standards like Brick Schema made us think we could do something useful there. But before we could do anything interesting with the data, we discovered we had to get it out of the buildings in the first place. That discovery eventually transformed the startup into Nobody Engineering. So I left construction because of the atmosphere and eventually found my way back to buildings because of data.
What was happening in the building automation and infrastructure space that made you believe there was a need for an independent data layer rather than another building management system?
I don’t think we started with a grand theory about what the building automation industry needed. We were trying to build software that could work with buildings, and kept running into the same problem: the information and controls we needed were locked inside equipment that was already installed. Sometimes there was a standard protocol, sometimes a proprietary one, and sometimes the only practical interface was a little display with buttons. Even when the technology allowed access, getting permission, documentation or credentials could be a project of its own.
The strange thing is that buildings are already full of perfectly functional automation. A building might have equipment from several manufacturers, installed over several decades, and there is usually no sensible business case for replacing all of it just to use a new digital service. Yet that’s often what the industry makes you feel you have to do.
Another supervisory system wouldn’t solve the underlying problem; it would still depend on connecting all that equipment, and could become another system the owner was tied to. We thought it made more sense to separate connectivity from applications altogether. Connect the equipment once, independently of the manufacturer, and let building owners and service providers decide what software to use. We don’t need to be the people optimising the ventilation or running the property. We need to make it possible for the people who do those things to work with the existing systems.
The idea behind Nobody is to make existing buildings work with modern software without ripping out the infrastructure already in place. When did you realise this could become a company?
It was less a moment of sudden certainty than a fairly painful discovery. We had a pilot with a city where the ambition was to connect around 200 buildings to our original software platform. We managed three. The software wasn’t really the obstacle. We were running into old controllers, closed interfaces and an industry in which everyone had become accustomed to the difficulty of accessing building automation.
I told a friend about the situation and he said,”Nobody is interested in that. They would just replace the old systems”. But the owners didn’t have the money to replace them, and in many cases there was no good reason to. That’s where the name Nobody came from, and our tagline is still “Nobody cares about your building automation.” I’ve since come to think that it’s not so much that nobody cares; it’s that nobody dares to touch it.We regularly see companies installing new IoT sensors to measure things the building’s existing automation already measures. And I understand why: if you’re unfamiliar with automation, learning how to access an old, complicated system can seem riskier and more expensive than simply installing a new sensor. But it means we’re duplicating perfectly functional infrastructure because working with what’s already there feels too overwhelming.
Eventually we accepted that the connectivity problem was more important than the application we’d originally set out to build. In 2020, we changed direction and started developing software agents that could communicate with the equipment on its own terms, including through operator interfaces never intended for software integration. We filed the patent that December. For me, that pivot was a kind of rebirth for the startup. We weren’t starting a separate company; we were finally discovering what this one needed to become. Once we had connected systems that supposedly couldn’t be connected, the opportunity became much harder to ignore.
You’re working with buildings of very different ages, sizes, and automation systems. What did you learn from the early buildings you connected that changed how you thought about the product?
One of the early buildings we connected was heating its supply air and then cooling it again before sending it into the rooms. It had apparently been doing that for years. That’s a pretty good illustration of what happens when the equipment works but nobody can easily see what it’s doing. The potential value of the data was obvious, but the path to getting it was anything but.
We also learned how much friction is built into the status quo. The manufacturer might be the only party with the tools or documentation, the maintenance company might not have the credentials, and the owner might not even know exactly what is installed. Sometimes opening a connection becomes a commercial discussion rather than a technical one. The existing vendors aren’t necessarily doing anything irrational: their business models were built around supplying and maintaining complete automation systems, not making it easy for independent software to work with them. But the result is that useful equipment becomes unnecessarily isolated. We had to learn to work without assuming cooperation from the original manufacturer, and make each subsequent installation is easier than the first. It took us longer to understand what that independence meant to building owners themselves. The value was immediately clear to companies delivering energy and building services: they wanted access to equipment so they could deliver their own expertise. But building owners are an important customer group for us too. One of our first portfolio customers has older, technically complex properties where wholesale automation upgrades would be costly and often unnecessary. Their head of real estate understood that digitalising those buildings wouldn’t be a single project with one provider. It would be a series of deployments, starting with basic services and adding more sophisticated ones over time. We now forward alarms to one provider, integrate another provider’s AI and enable a shared supervisory system across their properties. They can introduce or change services without starting the integration work from scratch each time.
We’re also seeing requirements from owners of larger, more demanding properties who need greater control over where the infrastructure runs and who can access it. That’s part of why we’ve been making the platform more distributed and less dependent on a single cloud provider. It can run on-premises, bring data from separate IoT systems back into building automation, and expose narrowly scoped interfaces to partners. These are capabilities we’re developing around real customer needs, not a claim that every proposed deployment is already live. The broader lesson was that we aren’t selling building owners another application. We’re giving them the freedom to choose and deploy applications on their own terms.
Nobody connects automation systems from many different manufacturers and generations, including equipment without modern interfaces. What has been the biggest technical challenge in making that work?
The long tail of building automation. Supporting a modern, well-documented protocol is one thing; supporting decades of proprietary controllers, undocumented serial connections and peculiar operator interfaces are something else. We started by buying second-hand controllers online and reverse-engineering them, and we still do that. Sometimes the quickest way to understand a system is to get the actual hardware onto a desk and see what it does.
Our first integration agent, essentially a software robot navigating a controller’s serial menu, took months to get to an MVP. Today we support more than 75 controller models, and when a customer portfolio introduces unfamiliar equipment, our team can sometimes develop several new agents in a week. That’s the result of years spent building reusable integration software, tooling and deployment processes. Each system has its own surprises, but we’re much better at knowing where to look and how to turn what we learn into something we can use again. Another important decision was to keep the hardware simple. We run Python-based integration agents directly on inexpensive industrial gateways running OpenWrt Linux. Some competing approaches use a similar gateway merely to connect a separate, expensive automation controller to the internet. We don’t think that extra layers should be necessary. We also have a European patent, granted in September 2026, relating to accessing and controlling systems through their existing operator interfaces. But the patent is only one piece of it. The real achievement is making all these difficult integrations practical to deploy and maintain at scale.
One of Nobody’s core ideas is “your buildings, your data, your choice of software” Why is data ownership and vendor independence becoming increasingly important for building owners and operators?
Building owners can own every piece of equipment in a property and still have surprisingly little freedom to use it. Access to data may require a manufacturer’s software, a paid integration or permission from someone who installed the system years ago. If a product is discontinued or a vendor changes direction, the owner can be pushed toward replacing equipment that still works perfectly well. I’ve sometimes called myself the Robin Hood of proptech, because the balance of power has been so heavily tilted toward the manufacturers.
Independence isn’t just about getting data out, though. It also means being able to choose and change the services that use it. We don’t want to replace one lock-in with another. We provide the infrastructure, and energy companies, facility managers, engineering firms and building owners can use the software that makes sense for them. As AI becomes part of those workflows, the same principle applies: customers should be able to choose their models and where they run. We don’t sell tokens. We’re building the connectivity, data structures and secure access that make different kinds of software possible, rather than trying to own every application built on top.
You’ve designed Nobody to be installed without a major capex project or disruption. How important was it to make deployment this simple, and what did you have to solve behind the scenes to make that possible?
Simplicity was never an optional feature. If connecting a building requires a major investment decision, a tender and months of engineering, it isn’t going to happen across thousands of ordinary buildings. That’s why we provide the edge devices as part of a subscription rather than selling the customer another piece of hardware to own. But the commercial model only works if installation and maintenance are genuinely repeatable.
We’ve spent years getting there. We built the integration agents, remote management, onboarding tools and a mobile application for field technicians, and we’ve kept refining the physical installation. Today a typical site takes roughly one technician-hour to install.
If we already know the controller, our own integration work may take only a few minutes; if we don’t, we can often develop the missing support remotely. We also have to manage security, remote access and safe control so that the building’s own automation continues doing its job if our connection disappears.
We always believed deployments would eventually have to become this straightforward. What has changed is that we can now demonstrate it: with one customer we’re currently rolling out around 30 buildings a week. That isn’t our total company-wide deployment rate, and we’re not claiming every building is equally simple, but it shows what the model can do. In much of this industry, connecting a single building can still be treated as a substantial integration project. That’s the difference we’ve been working to create.
Nobody has been backed by investors including Icebreaker and Kiilto Ventures, alongside proptech founders and operators. What were you looking for in your early investors beyond capital?
I think the most valuable thing an early investor can bring is the ability to see an opportunity before there’s an obvious market category or a neat set of numbers to describe it. We were working on something that was technically difficult, in an industry that isn’t known for moving quickly. It helped to have people who understood the scale of the underlying problem and were willing to challenge how we approached it.
There was a particularly memorable moment around our pivot. We’d connected an old building with an automation system at an Atmostech site, and I posted about it on LinkedIn. A friend who was a Sequoia Scout saw the post and told me,”Drop everything you’re doing and focus on that alone. Then I’ll invest” That was an investment in the direction we were taking, not just in the product we’d already built. It was also useful external validation: someone saw the potential in a technical breakthrough that most people outside the industry wouldn’t have understood at all.
We’ve had backing from investors including Icebreaker, Kiilto Ventures and others as the company has developed. Beyond capital, what matters is having people who can help you think clearly about the size of the opportunity, the business model and the decisions that will actually get you there. Especially when you’re building infrastructure, it’s easy to spend years solving interesting technical problems. You also need people who keep asking how it becomes a scalable business.
What has been the most difficult part of convincing the market to think differently about building infrastructure, and how have those conversations changed over time?
For years, the difficult part was that almost everyone recognised the integration problem, but few organisations had an incentive to solve it across the industry. Building owners expected their automation suppliers to handle it, the suppliers had established ways of working, and software companies dealt with the cost one building at a time. We initially worked mostly with startups developing energy optimisation and other services.
They understood immediately why our infrastructure mattered, but even a successful startup might only be adding a relatively small number of buildings each year. More recently we’ve shifted much of our attention to established engineering consultancies and facility management companies. These businesses already have the customers, thousands of employees and enormous amounts of building expertise. What they often don’t have is a practical way to turn that expertise into repeatable software products. Their economics are based on delivering services and billing projects; it’s difficult to justify building a software platform when the first customer isn’t paying for all that development. We can provide the common infrastructure and tools so they can focus on what they know about buildings, rather than creating their own integrations and software foundations.
That changes the conversation considerably. We’re no longer just explaining why a data layer would be useful; we’re discussing how an existing service organisation could deploy new capabilities across a large property portfolio. We have hundreds of buildings connected, one customer is currently rolling out around 30 buildings per week, and we’re working with other organisations that have the potential to deploy at much larger scale. The opportunity is becoming more concrete, although we’re careful to distinguish what we’re already doing from what we believe we can do next.
If you look five years ahead, what do you want the relationship between buildings, their data, and the software running on top of them to look like?
I’d like to connect software to a building to become completely unremarkable. A building owner or service provider should be able to choose a tool, give it appropriate access to the equipment and start using it without negotiating with multiple automation vendors or commissioning another bespoke integration. The building’s existing systems should remain in place, and the software should be replaceable independently of the hardware.
I also think the industry’s obsession with the “single pane of glass” is reaching the end of its useful life. We keep trying to build ever larger supervisory interfaces, but I suspect people will increasingly interact with buildings through conversations, agents and small applications created for particular jobs. We’re beginning a pilot around a simple example: technicians need to adjust PID-loop tuning parameters, a task that currently means navigating awkward supervisory systems or specialised tools. Instead, a customer could describe the mobile tool they want and use AI to help create it, with Nobody providing the underlying connection and controlled access to the relevant parameters. That’s an early direction we’re exploring, not a claim that AI is already autonomously running all these buildings.
For that future to work, software also needs to understand what the data means. We’re developing semantic mapping using open standards such as Brick Schema, so applications can understand which points belong to which systems and what they represent. Some of that work is still being tested. Customers should also be free to use their own AI provider or run models locally, rather than becoming dependent on ours. Ultimately, I don’t think our role is to predict the winning interface or application. It’s to make sure that whatever people want to build can work with the buildings that already exist.
What advice would you give to founders building in a traditional, infrastructure-heavy industry where changing the status quo takes time?
Choose a problem you find genuinely interesting, because you’ll probably be spending more time with it than you expect. I’m proud of our persistence, but I don’t think persistence means sticking rigidly to your first idea. We’ve changed our technology, product, customers and business model considerably over the years. What stayed consistent was the problem we wanted to solve.
A friend once told me,”If that’s the hill you’ve chosen to die on, then go for it ”It’s a dramatic way of putting it, but I understood what he meant: some problems are difficult enough that you have to make a conscious decision to commit to them. That doesn’t mean you should stop listening or refuse to change course. Quite the opposite. You have to be willing to change almost everything except the reason you’re doing the work. I’d also be careful about what you decide not to build. We could have tried to become an energy optimisation company or a facility management software provider, but other people already understand those jobs far better than we do. Our contribution is the missing infrastructure. Working with partners who already have customers and expertise has made much more sense than trying to recreate an entire industry around ourselves. It took us time to learn that, but it’s also what makes the opportunity interesting now.
