We closed a $1M angel round in November 2025. This is a short post explaining what we are going to do with it and why those specific things, not others.
We are four people. We started Voltpathio in 2023 with a specific thesis: that building energy optimization was stuck in a reactive paradigm — systems that adjusted after the fact rather than ahead of the curve — and that a 48-hour predictive window could change the economic math meaningfully. We spent the first year building and validating that thesis with a small number of early pilot facilities. The results were good enough that we started taking money seriously.
The angel round is not transformative capital. It does not change our fundamental approach. It does three specific things that we could not do without it, and we want to be transparent about what those are.
Thing One: Deeper Integrations
The current state of our integration stack is honest but incomplete. We support BACnet, Modbus, and MQTT, which covers most commercial BMS installations we have encountered. What we do not yet have are native connectors to the specific vendor implementations that dominate the installed base: Siemens Desigo CC, Johnson Controls Metasys, Honeywell EBI, Schneider EcoStruxure Building.
These systems each have their own implementation quirks on top of the standard protocols. BACnet interoperability in principle does not mean frictionless integration in practice. Every implementation has vendor-specific object structures, proprietary alarm handling, and undocumented behaviors that only show up after you have spent hours debugging a connection that "should work" per the spec but does not.
Right now, when we connect to a facility running Metasys or Desigo CC, our integration engineer spends time that should not be necessary working through those platform-specific issues. That time costs us and costs the customer in delayed time-to-value. Part of this round goes toward building out tested, documented connector libraries for those four platforms — work that will reduce integration time from weeks to days for the majority of our target customer base.
We are also planning integration work on the utility data side. Green Button Connect (the standardized API for U.S. utility interval data) is theoretically available from most major utilities, but the implementation quality varies significantly. We want to handle the per-utility setup complexity so customers do not have to.
Thing Two: The Multi-Site Dashboard
The current product is building-centric. You log in and see one facility's data: its forecast, its schedule recommendations, its savings against baseline. That is fine when you are selling to a single-building operator, but it is not what a portfolio manager or sustainability director needs.
The multi-site dashboard is a view layer above the individual building view — a rollup that shows energy performance, savings, and forecasts across a group of facilities in a single screen. The underlying data is already there (every connected building streams 15-minute telemetry to our backend). What is missing is the cross-site aggregation, the comparative benchmarking between facilities, and the portfolio-level reporting that sustainability teams need for disclosure and internal goal tracking.
This is not a trivial feature. It requires rethinking how we model the relationship between sites, handle sites in different utility territories with different tariff structures, and normalize consumption data across buildings with different operating profiles. The data model work is most of the effort. The UI is the smaller piece.
We expect to ship a beta version of the multi-site dashboard in mid-2026. Early access will go to customers who have multiple facilities already connected to Voltpathio — they are the right people to test whether we have gotten the comparative benchmarking logic right before we open it more broadly.
Thing Three: The 72-Hour Prediction Window
The current product forecasts 48 hours ahead. We chose 48 hours originally for pragmatic reasons: weather forecast accuracy degrades significantly beyond 48 hours, and the incremental scheduling value of a 72-hour view was not clear to us before we had real deployment data.
Now we have data, and the pattern that emerged changes our thinking. The facilities where 48-hour prediction has the most scheduling impact are the ones with longer thermal lag — larger buildings, heavier construction, less responsive HVAC systems. These are also the buildings where 48-hour ahead is barely enough lead time to pre-condition before a weather event. A heavy-construction office building in an extreme heat event might need 36–42 hours of pre-conditioning to get the building's thermal mass to target before the hottest part of the day arrives.
That leaves almost no margin at 48 hours. A 72-hour window gives us scheduling flexibility that 48 hours does not. The weather forecast quality issue is real — we will be transparent that 49–72 hour forecasts are probabilistic in a way that 1–48 hour forecasts are not, and the scheduling recommendations will reflect that uncertainty with wider confidence intervals and more conservative commitments. But having the extended view changes what is possible for the facilities where it matters most.
The technical work is partly model retraining (incorporating 3-day weather forecast data into our feature set) and partly infrastructure work (our forecast generation pipeline needs to handle a longer horizon without the latency becoming a problem for real-time scheduling). We expect this to be available as an opt-in feature for compatible facility types — large commercial buildings and industrial facilities with significant thermal mass — rather than a universal upgrade.
What This Round Is Not For
We are not hiring a sales team. We are not running paid acquisition. We are not building a mobile app.
Every one of those might make sense at some point, but none of them makes sense now. We have a product that works. We do not yet have the integration depth, multi-site view, or extended forecast horizon that would make it work well for the full range of facilities in our target market. Getting those right is a prerequisite to scaling customer acquisition — selling a product that does not yet do what the next 50 customers will need is how you burn goodwill and churn.
The angel round is engineering capital. It funds the three things that will make Voltpathio meaningfully better for the customers we want to serve in 2026 and beyond.
A Note on the Raise Itself
We are grateful to the individuals who invested in this round. We are not disclosing their names here — they invested as private individuals, and we will respect that.
What we can say is that the people who wrote us checks did so because they had direct experience with the problem we are solving. These are people who have managed facilities, dealt with BMS integration projects, or worked in energy procurement. That context matters to us more than the check size. We want investors who will tell us when we are wrong about something rather than ones who will nod along.
We will write again when we have something meaningful to show for this capital. If you are a facility manager or sustainability lead who wants to follow along or talk about what we are building, reach out at [email protected]. We are a small team and we read everything.
— Andrew Kowalski, CEO & Co-Founder, Voltpathio