Virtual Power Plant Software: Why Your DER Fleet Under-Delivers on Dispatch Day

Why a DER fleet breaks the software that enrolled it

It is 3:12pm on an August weekday. The market operator issues a dispatch instruction with a ten minute notification window. Your fleet is 12,000 devices: roughly 6,000 thermostats across three brands, 900 residential batteries, 2,400 grid-interactive water heaters, and 40 commercial sites sitting behind a building controls vendor that speaks BACnet and nothing else. The dispatch console fires. Two thermostat clouds acknowledge inside thirty seconds. The third queues your commands and drips acknowledgements back over four minutes, and you cannot tell whether the setpoint landed on a device or only on the vendor's message bus. The batteries are at 38 percent state of charge because the previous event ran long and nobody reset the reserve floor. At the end of the hour, the market settles you against a meter-derived baseline and your award is delivered at 71 percent.

The stack around that hour is usually an aggregation platform for enrollment and device control, a workbook for the bid stack, the ISO portal for offers and settlement statements, a second workbook for participant payments, and a support inbox absorbing opt-out complaints. Every piece is competent at its slice. None of them holds the object the business actually runs on: an award with a device-level dispatch plan, an expected contribution per device, a live delivery estimate during the interval, and a settlement line that traces back to the exact commands sent and the exact meter intervals that produced the payment. That join lives in one operator's head and in a workbook rebuilt after every event.

The cost of that gap is not subtle. Under-delivery on a capacity obligation reduces next season's award, which compounds, and overpaying participants from a sheet that used telemetry rather than the settled baseline comes straight out of margin.

Problem 1: the notification window is shorter than your slowest device cloud

Market products differ but the shape is constant. You have minutes, sometimes seconds, between instruction and the start of the performance interval. Your dispatch path runs through third-party clouds you do not own, each with its own rate limits, batch sizes, retry behaviour and private definition of what an acknowledgement means. One vendor confirms receipt at the API boundary. Another confirms only when the device reports back. A third confirms nothing you can act on and you learn the truth from telemetry twenty minutes later.

AutoGrid Flex and EnergyHub Mercury both maintain broad device integration catalogs, and if your entire fleet sits inside one of those catalogs the devices will be controlled. What neither gives you is authority over dispatch ordering when the window is tight. You cannot instruct the platform to fire the slow-acknowledging brand first, pre-position the fast brands, and substitute battery discharge for the thermostats a model says will not respond in time. Tesla Autobidder is a strong bidding engine but it is built around Tesla hardware economics and is not the answer for a mixed-brand residential fleet. Virtual Peaker is good at utility-branded enrollment and customer control and thinner once the market side gets complicated. Enel X operates programs as much as it licenses software, which is fine until the utility decides it wants to own the participant relationship and the underlying data.

What a custom build does differently: it treats dispatch as a scheduling problem with per-channel latency budgets. Each integration carries a measured acknowledgement distribution taken from your own event history rather than a vendor's nominal figure, and the dispatcher orders commands so the slowest path starts first. Devices predicted not to deliver are replaced from a reserve pool before the interval opens rather than mourned after it closes. In the fleets we have worked on, latency-aware ordering plus a reserve pool is what moves measured performance, and that movement decides whether a capacity award holds or gets trimmed.

Problem 2: your baseline is the market's opinion, not your telemetry

You know precisely what every device did, because you are reading it at one minute resolution. The market does not care. Performance is measured against a baseline computed from interval meter data under the rules of that specific product, which might be an averaging method with a day-of adjustment, a regression, or a control group. Your telemetry and the settled number will disagree, and the disagreement is where the money goes.

Aggregation platforms show telemetry-based performance dashboards. Those charts are useful for operations and close to useless for revenue. If you cannot recompute the market baseline yourself, per participant and per interval, before the settlement statement arrives, you cannot challenge a statement, you cannot forecast your own revenue with any confidence, and you cannot answer a commercial participant who asks why this event paid less than the last one when they did the same thing.

A custom build implements the baseline method of the products you actually bid into, runs it against the same interval meter data the market uses, and stores every input so the calculation is reproducible a year later when someone asks. Then it does the part that changes decisions: it runs the baseline forward as a forecast, so before you submit an offer you know your expected measured delivery under that method, which is a materially different number from your expected physical curtailment. Bidding the physical number is how aggregators end up short.

Problem 3: paying thousands of participants is an accounting system, not a report

Participant payment is where DER programs quietly become finance operations. A residential customer enrolled on the eleventh of the month, opted out of one event, has two devices on different tariff terms, and churned before the quarter closed. A commercial participant has a demand charge interaction, a shared savings split, and a contract that pays on nominated capacity rather than measured delivery. Multiply by thousands and put a tax reporting obligation on the commercial side.

Nothing in the aggregation platform layer is built to be a subledger. It reports what devices did. It does not hold the accrual, the adjustment, the reissued payment after a settlement true-up, or the audit trail explaining why a payment changed. So the payment run gets built in spreadsheets and the company discovers, usually during a finance review, that the participant payments across a season do not reconcile to the market revenue that funded them.

A custom build makes settlement a first-class ledger. Every event produces immutable device-level records, those roll into participant statements under the tariff terms in force on that date, and adjustments are posted as new entries rather than edits. Participants can see their own event history and payment basis in a portal, which cuts the support volume more than any other single feature, because most opt-out complaints are actually payment confusion.

What a custom VPP build has to include

• An integration layer with one adapter per device cloud, each carrying its own rate limits, retry policy and measured latency profile, plus a local protocol path for commercial sites on BACnet or Modbus.
• A dispatch engine that plans device-level contribution against an award, orders commands by latency, and holds a reserve pool for substitution.
• A state model per device covering enrollment status, opt-out state, availability, and for batteries the state of charge and reserve floor that dispatch must respect.
• Market baseline computation implemented per product, run both as a forecast before bidding and as a check against the settlement statement afterwards.
• A participant subledger with tariff versioning by effective date, adjustments as postings, and a customer-facing statement view.
• Telemetry ingestion and interval meter ingestion as separate pipelines, because they arrive at different latencies and are used for different decisions.
• An event replay capability, so any past event can be reconstructed exactly for a dispute or a regulatory question.

What it costs and how long it takes

From the energy and grid services work Digital Heroes has delivered, the honest shape is this. A first release covering two or three device integrations, latency-aware dispatch, opt-out handling and a defensible settlement ledger runs $90,000 to $180,000 and ships in 14 to 20 weeks. That is a system your operations desk uses on the next event, not a pilot. A full platform adding baseline forecasting, participant payment runs with a customer portal, enrollment and churn, and a second market product runs $250,000 to $600,000 phased across 9 to 15 months.

What pushes the number up in this category specifically: the count of distinct device clouds, because each vendor API is its own integration with its own sandbox access problem and its own certification queue. Battery fleets, because state of charge management and warranty-aware cycling are real modelling work rather than an on-off command. Participation in more than one ISO, since each product carries a different baseline method, different telemetry obligations and a different offer format. And commercial and industrial sites, because every building controls estate is bespoke and the site survey is unavoidable.

What holds the number down: launching with the two device brands that make up most of your enrolled capacity, one market product, and a manual payment approval step for the first season. You can automate the payment run once you trust the ledger, not before.

Build versus buy, and when buying is right

Buy if you are a utility running a straightforward thermostat-only demand response program under your own tariff, with one device brand and a few thousand participants. Virtual Peaker and EnergyHub will do that competently and a build would be an expensive way to arrive at the same place. Buy if you are still testing whether a DER program has commercial legs, because that answer is not a software question.

Build when two or more of these are true. Your fleet spans three or more device brands and you are measurably losing performance to acknowledgement latency. You bid into a wholesale market product and cannot reproduce the settlement baseline yourself. Participant payments are calculated outside the platform and no longer reconcile cleanly to market revenue. Your batteries need cycling limits enforced during dispatch because a warranty depends on it. Or the platform that runs your program also owns the customer relationship, and your strategy requires that you own it.

The tipping point is not device count. It is the moment your dispatch decision, your revenue and your customer payments stop being three separate reports and become one connected system that nobody sells off the shelf because it is shaped by your device mix, your market and your tariff.

How to choose a developer for VPP and DER software

Ask them to explain how they would handle a device cloud that acknowledges a command but never applies it. A developer who has shipped this will talk about reconciling command intent against telemetry and flagging silent failures per vendor. A developer who has not will describe an API call and a success response.

Ask them to draw the settlement path from a market instruction to a customer payment. You want to see interval meter data and telemetry as separate inputs, the baseline method as a versioned calculation, and the participant ledger as immutable postings. If they draw one table called events, they are going to learn energy settlement on your budget and your regulator's timeline.

Ask which device integrations they have actually built against and get vendor names, not a category. Thermostat clouds, battery inverter APIs and commercial building controls are unrelated engineering problems, and a firm that has done one will say so plainly.

Ask who owns the code, the cloud accounts and the device integration credentials, and get it in writing before kickoff. This matters more here than in most categories because the integration layer is the asset. At Digital Heroes the client owns the repository from the first commit, and if a vendor hesitates on that question in a DER build, that hesitation is the answer. Start by pulling your last three events and asking whether anyone can reconstruct, device by device, why the measured delivery differed from the plan. If nobody can, that is your first scope.