Contents
When is a standard product enough?
As long as your installation matches the picture the product was built for: one manufacturer, a manageable scope, an optimisation strategy from the catalogue. Then the manufacturer’s own system is practically unbeatable — available sooner, cheaper to enter, maintained by someone else. The tipping point almost never comes at purchase, but at the third special case.
How do the two routes compare?
| Criterion | Standard software | Custom development |
|---|---|---|
| Time to first value | Days to weeks. Connect the installation, create an account, done | Weeks to months. The data foundation comes first |
| Device variety | The vendor’s device list. Anything outside it not at all, or via workarounds | Arbitrary. Connectivity sits in its own processing stage; new devices do not touch the analysis |
| Optimisation logic | Predefined strategies, adjustable through parameters | Free. Market prices, CO₂ intensity, forecasts and operational constraints as equally ranked inputs |
| Market data | If available, as a vendor feature using the vendor’s data source | Day-ahead prices from European bidding zones and grid CO₂ intensity directly as inputs |
| Data sovereignty | Usually the vendor cloud, location and retention per their terms | On premises, German cloud or hybrid — you decide where processing happens |
| Running cost | Licence per installation, metering point or charge point. Scales with expansion | Operation and maintenance. No licence scaling as you add devices |
| Historical data | Retention per vendor terms, export often limited | Entirely with you, in a time series database of your choice |
| Dependency | The vendor’s roadmap, pricing model and survival | Your own estate. Only carries if it is documented |
| Risk | Low and known | Higher. Grows with unclear requirements, shrinks with a solid data basis |
How do you spot the tipping point in advance?
Three questions answerable without a project:
How many device manufacturers are involved — today and in five years? With a single manufacturer, their own system is usually unbeatable. From the third onwards, connectivity itself becomes the actual product, and that is exactly the effort a standard product does not take off your hands.
Can your optimisation logic be expressed in the product’s parameters? If you want to combine day-ahead prices, CO₂ intensity and your own load profile — or operational constraints such as shift planning — usually not. Parameters allow variation within a pre-conceived strategy, not a different strategy.
Are there requirements to keep data in house? If so, that often decides on its own, independently of everything else.
What is the middle path?
Not a rebuild, but standard components with your own decision layer. Inverters, storage and wallboxes stay with the manufacturer; data consolidation and optimisation are built individually.
For smaller installations Node-RED is a viable entry point: quick to set up, sufficient for rules of the kind “if generation exceeds consumption, then charge”. This approach reaches its limit as soon as forecasts, historical analyses and several simultaneous constraints come into play — at that point the flow becomes a program nobody can survey any more.
That is where it moves into an event-driven architecture, as in EcoPulse: device connectivity, ingest, state projection, API and interface as separate stages. The effort is higher, but the structure also carries the twelfth manufacturer.
Why is device connectivity the real cost centre?
Because it is never finished. Modbus and SunSpec cover part of it; the rest runs via vendor-specific interfaces that change with firmware releases. Every new device is a small integration project.
The difference between an expensive and a sustainable solution lies in whether that effort is contained. If connectivity sits in its own stage, a new manufacturer costs exactly that stage. If it is interwoven with the analysis, it costs the whole system every time. That single design decision drives the operating cost of the coming years more than the choice between buying and building.
What about the way back?
It is rarely asked and yet the hardest question: what happens if the decision was wrong?
Leaving a standard product is usually expensive — historical data sits with the vendor, export is limited, and the optimisation history is not transferable anyway. Leaving a custom system is easier, provided the data lives in an open time series database and the connectivity is documented.
That is not an argument against standard software. It is an argument for checking exportability when you buy — and documentation when you build.
Where do standard products typically stop?
At prediction. Monitoring and rule-based control are handled by practically every product: current consumption, current generation, a threshold, an action. But as soon as the decision depends on tomorrow, things get thin.
Price-led charging needs the day-ahead curve for the coming 24 hours. Self-consumption optimisation needs a generation forecast. Peak shaving with storage needs a load forecast, otherwise the battery is empty when the peak arrives. These three models are the actual functional core of energy management — and the part a product either brings or does not.
If it does bring them, the decisive question is whether the forecast is trained on your data or on a generic profile. A generic load profile describes an average operation; your operation is not one.
What does the five-year calculation look like?
The usual comparison sets licence cost against development cost and stops there. It overlooks three items:
- Licence scaling. Standard products usually bill per installation, metering point or charge point. Every expansion pays again. With a custom system the twelfth charge point costs the connectivity, not the licence.
- Integration effort despite the standard product. No product covers your entire device landscape. Whatever is missing gets connected via workarounds — and that workaround is custom development, only without the structure a planned custom build would have.
- Maintenance of the custom system. Conversely: a self-built platform has running costs for operation, dependency updates and adaptation to firmware releases. Leaving those out of the calculation compares the wrong things.
The honest calculation puts both sides down in full. In smaller installations the standard product almost always wins. Above a scale where licence scaling and integration effort rise at the same time, it tips.
What role does charging infrastructure play?
It is the most common trigger for the switch. As long as the topic is generation and consumption, the world is manageable. As soon as vehicles enter, constraints appear that no catalogue product knows: which vehicle has to travel how far and when? Which charge point takes priority? What happens when the grid connection cannot supply the sum?
These rules are operation-specific. They cannot be parameterised, because they are not a variation of a pre-conceived strategy but a strategy of their own. That is exactly where the custom decision layer arises in our projects — not out of a desire to build, but because the requirement does not appear in the catalogue.
What do we recommend before anything is decided?
An analysis of your existing measurement data. That shows where the levers actually are — peak shaving, self-consumption or load shifting — and whether that lever carries the investment.
It is a few days of effort and replaces a discussion about products with one about numbers. In more than one case the result was that a standard product is enough. That is a legitimate outcome and one we welcome: we do not want to build a project that does not pay for itself.
Details under Energy management & e-mobility.