Why 49Komma8 Stopped Building Their Own BESS Digital Control Platform

At 49Komma8 we develop, build, and operate battery storage systems across Switzerland. We handle the whole lifecycle, including site evaluation, construction, operation, and eventually decommissioning. Somewhere along the way, as we kept adding sites, our approach to operational data turned into its own problem. Here’s what happened, and what it taught me about buying versus building.

Who we are

We’re one of the largest and fastest-growing developers of battery storage in Switzerland. Bonaduz is a good example of where that growth is heading: once it comes online in 2027, the 50 MW, 110 MWh system we’re building there is set to be the largest battery storage project in the country. Our sites already in operation range from around 10 MW each up to that scale, and together they total 98.8 MWh today. Every one of these systems does the same fundamental job: storing surplus solar power during the day and releasing it when the grid needs it, helping keep the grid stable and supply secure. It’s also where our name comes from — 49.8 hertz is the critical frequency threshold we work to keep the Swiss grid above.

Running that many sites well means we’re responsible for a lot of operational data. That’s the part of the business this post is about.

What we were doing before

For a while, our approach to BESS data was typical of what I see other operators doing: we pulled data through the BMS interface at each site, uploaded it to Google Cloud, stored it in BigQuery, and visualized it with Grafana. We could see our operational data in elegant charts and dashboards, but identifying the high-priority issues was still a manual process.

But as we started adding sites faster, the time it took to stand up that system began to hold us back. Every new site meant reconfiguring things from scratch and pulling someone away from other operational work that needed their attention. That lag limited how quickly we could bring new capacity, and new revenue, online.

That’s the part people underestimate about building this kind of thing yourself. It’s not that it doesn’t work, but the cost doesn’t stop after you build it. It’s there every single time you scale.

How we found Ardexa

We were introduced to Ardexa through a leading battery analytics provider, who recommended it as a way to get more reliable data into their platform. What we expected was a reliable data acquisition system that would feed our BESS analytics solution. What we found was that a great deal more came with it: monitoring, interactive analysis, and powerful alerting, all of which we now use every day.

Ardexa shipped us preconfigured hardware, handled the setup and configuration remotely, and had our first site live within weeks. What really got my attention was what happened after that: once we had one site live, onboarding a second site with similar architecture took less than a day from the time the hardware shipped, and our own share of that day was a small fraction of it. We provided the information Ardexa needed to configure the system and physically installed an IPC on site. Ardexa did the rest. Under our old homegrown setup, onboarding a new site was slow and got more expensive as we grew. Staying one of the largest and fastest-growing battery storage developers in Switzerland gets a lot more achievable when adding the next site costs us a morning instead of a month.

What it changed day to day

The clearest change has been in how our mornings start. I log into Ardexa first thing, and the dashboard gives me an immediate read on whether everything is running the way it should be. By the time I get to my email, most of the warnings or faults from overnight have already been flagged through Ardexa’s alerting, often before anyone had to go looking for them.

Here’s a concrete example: our SMA inverters occasionally run into communication issues, and around 15% of the time they turn into an outage. With Ardexa, we catch and resolve these fast enough that our asset managers usually never even know there was a problem. That’s the difference between an emergency and routine maintenance.

Part of why that works is that the alerts themselves are configurable, not just on or off. For something like inverter comms, I’ve got it set to high severity, so it doesn’t get buried under lower-priority notices. I could go further and file alerts into categories like safety or revenue-impacting, but so far severity on its own has been enough. Plus, it only fires once the condition holds for a few minutes, which is long enough to rule out a momentary blip but short enough that we’re still ahead of it. That kind of control is a big part of why the alerting gets used instead of ignored.

Why owning our data matters as much as monitoring it

One thing I didn’t fully appreciate going in: the same data feed that powers our own dashboards is also what our battery analytics platform uses, through a straightforward API integration. That means we’re not stuck choosing between our own visibility and our vendor’s analytics. We get both from a single pipeline, and if we ever wanted to bring in a different analytics tool, or run more than one at once, it’s simply a matter of issuing an API token.

That’s a less obvious benefit, but it might be the more important one long-term. We’re not locked into anyone. The data is ours, and we decide who gets to use it and how.

What this taught me

As we keep adding sites, a reliable data infrastructure becomes increasingly important. Reliable data and rapid fault detection aren’t just nice-to-haves in battery storage. Incidents can carry real financial or safety consequences, and the bigger our portfolio gets, the more that reliability must hold up without adding overhead as we grow.

That’s been our experience, anyway. If you’re running BESS assets and still stitching together your own data acquisition and monitoring system, it might be worth asking whether that’s where you want your best people spending their time.