Most energy tech companies pick a clean problem. Monitoring dashboards. Analytics platforms. Pretty graphs sitting on top of someone else's data. The physical world, the actual devices, the protocols, the hardware that lies about its own state, that's conveniently left to someone else.
We went the other way.
Sourceful has always been about the physical layer. Talking to actual devices. Sending actual commands. Getting confirmation that hardware did what it was told. This is an ugly problem, and we chose it on purpose.
Visibility is not a product. Control is.
There's a misunderstanding in energy tech about what "smart grid" means. Most people hear it and think monitoring. Data collection.
That's table stakes.
A utility needs to curtail 40 MW of solar in under a second. An aggregator needs to discharge two thousand home batteries simultaneously for a frequency regulation bid. A grid operator needs to shift ten thousand heat pumps off peak, right now, and know it happened.
This requires solving the integration problem at the device level. There's no abstraction layer that makes the physical world go away. And it requires local execution. Cloud API round-trips take two to five seconds. Grid frequency has to balance every single second. That's physics, not a performance gap you can close with better infrastructure.
If your coordination logic lives in a data center, you're structurally locked out of the markets that pay the most: frequency containment reserves, fast demand response, sub-second optimization.
We started local before "edge computing" became a buzzword in energy. That decision is now an architectural advantage that can't be replicated without starting over.
What we've shipped
We rearchitected our entire backend from the physics up. Not a feature release. A new foundation. The identity system, the control pipeline, the telemetry infrastructure, all redesigned around how the grid actually works.
On top of it, we've shipped a single binary that turns any hardware into a Sourceful gateway node. Our own Zap, partner hardware, off-the-shelf Linux boxes, a developer's laptop. Same software everywhere, same capabilities.
It does two things. First, it's a production gateway: connects to energy devices on the local network, runs drivers, executes control commands with deterministic timing, and keeps running when the internet drops.
Second, it's the integration platform itself.
Hugin: AI that learns the physical world
We've built an AI-first integration engine called Hugin that can point at an unknown energy device, scan it, figure out how it communicates, cross-reference our driver library, and produce a working, tested driver. In minutes. Not weeks.
The driver that the AI builds is the exact same driver that runs in production. There's no handoff, no rewrite, no separate dev environment. The tool that creates the integration is the platform that runs it.
The industry standard is one engineer, one device brand, weeks of reverse engineering. We have about thirteen OEM integrations today. With Hugin, the first integration is roughly 10x faster than manual development. By integration fifteen, the AI recognizes patterns across manufacturers and already understands 80% of a new device before it starts. By integration fifty, it's 100x the pace of anyone still hand-coding drivers.
The curve doesn't flatten. It steepens. Every driver teaches the AI about the next one. The messy physical world that everyone else avoids is literally the training data that makes our system smarter.
What actually scales
Most platforms treat integration as an internal engineering problem. Hire more developers. Grind through the backlog.
What actually scales is when the people who need an integration the most are the ones building it. The homeowner with the device in their garage. The electrician who installs that brand every week. They have the hardware physically in front of them.
With AI-first tooling, they don't need to be protocol engineers. They point the tool at their device, supervise the process, review the output, and submit a driver. That driver gets reviewed, signed, and distributed to every Sourceful gateway in the world.
One person solved their own problem. The entire network got smarter.
Four moats that compound
A moat is something that gets stronger the more you use it, and that competitors can't replicate without going through the same painful process. We have four, and they reinforce each other.
The driver library. Every validated driver represents real-world knowledge about how a device actually behaves, not how the documentation says it behaves. You can't generate this from a spec sheet. Every driver is a brick in a wall that competitors have to build from scratch.
The AI knowledge base. Every integration teaches the system about the next one. A competitor starting today begins at integration one. We'll be at fifty by the time they've set up their dev environment.
Local execution. Most teams default to cloud because it's easier. Then they hit the physics ceiling and discover there's no shortcut. We already cleared that bar.
The network. Every deployed gateway makes the platform more valuable to every other node. Utilities want one platform covering the most devices. More gateways attract more contributors. More contributors produce more drivers.
These four compound each other. More drivers feed a smarter AI. Faster integration deploys more gateways. More gateways attract more contributors. The flywheel accelerates with every turn.
What this means for you
If you own solar panels, a battery, an EV, or a heat pump, you own a piece of the grid. Your battery could earn revenue balancing grid frequency. Your EV could charge at the cheapest moment and sell power back at peak. Your heat pump could preheat your house when wind power is abundant and cheap.
The value is there. The markets exist and pay real money today. Your devices just can't access them yet, because nobody has solved the coordination problem at scale, across brands, at the speed the grid requires.
That's what we're building. And when it works, the hardware you already own becomes worth meaningfully more.
This post is based on Episode 74 of Coordinated with Fredrik, where we go deeper on the architecture and the thinking behind it.
