Energy / Automated demand response platform
Cloud-based demand response management system (DRMS) with OpenADR VEN managementBackend, cloud and DevOps engineering on an existing platform, with LLM-assisted delivery
Scaling an OpenADR demand-response platform on AWS serverless
Enersponse develops automated demand response and distributed energy resource management software that connects utilities, aggregators and energy consumers through OpenADR. Its DRMS already handled utility communication, event processing and distributed Virtual End Nodes (VENs) on AWS. As more energy assets and utility integrations were added, the platform's scaling, monitoring, deployment and event orchestration became harder to manage.
Keep utility demand-response events processing reliably as the number of VENs grew, support more OpenADR communication models including 2.0b, make the system easier to diagnose, and make deployment and testing more consistent.
- Product
- Cloud-based demand response management system (DRMS) with OpenADR VEN management
- Buyer
- Energy technology companies running cloud platforms for utilities, aggregators and distributed energy resources
- Engagement
- Backend, cloud and DevOps engineering on an existing platform, with LLM-assisted delivery
- Indeema scope
- Engineering team and origin, Architecture review, OpenADR and event processing, Backend APIs, Cloud, DevOps and support, LLM-assisted engineering
The product need
What had to become possible
Keep utility demand-response events processing reliably as the number of VENs grew, support more OpenADR communication models including 2.0b, make the system easier to diagnose, and make deployment and testing more consistent.
Ownership, made clear
Where the work started and what Indeema owned
Starting system
Cloud DRMS on AWS
Enersponse already ran a DRMS on AWS with OpenADR communication, event processing and VEN management.
Serverless architecture
The platform used AWS Lambda, SNS, CloudWatch scheduling, API Gateway, MySQL on RDS, Bitbucket Pipelines and the Serverless Framework.
Utility and partner integrations
External utilities and energy partners connect to the platform through its APIs and OpenADR endpoints.
Indeema owned
Engineering team and origin
Enersponse engaged Vakoms for this work in 2023. The work was delivered by the Vakoms engineering team, which became part of Indeema when the two companies merged under the Indeema brand in 2025.
Architecture review
Review the DRMS architecture, OpenADR flows, AWS infrastructure, deployment pipelines and event logic, and propose changes for scaling, observability and maintainability.
OpenADR and event processing
Improve VEN registration, event parsing and the event lifecycle, strengthening OpenADR 2.0a and 2.0b support.
Backend APIs
Improve the PHP backend APIs and web services for utility integrations, event management, OpenADR endpoints and monitoring, with Swagger documentation.
Cloud, DevOps and support
Rework the Lambda-based event orchestration, logging and deployment workflows, then support the platform with compatibility updates, monitoring improvements and testing.
LLM-assisted engineering
LLM coding assistants are part of the team's everyday programming workflow on the platform; every change is still reviewed and tested by the engineer responsible for it.
Worked with
OpenADR 2.0a / 2.0b
Communication between the DRMS and distributed VENs follows the OpenADR standards.
Utility providers
Utilities and external energy partners exchange demand-response events with the platform through its APIs.
AWS services
Lambda, SNS, API Gateway, CloudWatch and MySQL RDS run event execution, messaging, APIs, scheduling, logs and storage.
Product constraints
What made the engineering difficult
- 01
Several OpenADR models at once
The platform had to keep events synchronised across distributed systems while supporting more than one OpenADR version and utility communication model.
- 02
More VENs, more events
As VEN instances multiplied, the event-driven execution path developed bottlenecks.
- 03
Shared log streams
Shared CloudWatch log streams made it hard to see what a given component was doing and slowed troubleshooting.
- 04
Manual infrastructure steps
Parts of infrastructure management and deployment relied on manual work.
Engineering judgement
Decisions that shaped the product
Review before changing
Start with a full review of architecture, OpenADR flows, infrastructure and pipelines, and base the change proposals on its findings.
Build on the serverless model
Improve the existing Lambda-based architecture and event orchestration to handle the growing number of VEN instances.
Treat observability as platform work
Improve monitoring and logging directly, because shared CloudWatch log streams were making diagnostics difficult.
Document the API surface
Use Swagger-based documentation for the backend APIs that utilities, partners and internal teams integrate with.
Put LLMs in the engineering loop
Use LLM coding assistants to move faster on a protocol-heavy codebase, keeping code review, PHPUnit tests and the deployment pipeline as the quality gate.
Delivered product capability
What the product can do
- 01
OpenADR 2.0a and 2.0b handling
VEN registration, event parsing and event lifecycle handling for both OpenADR versions.
- 02
Distributed event workflows
Reworked Lambda-based orchestration for demand-response events across VEN instances.
- 03
Monitoring and logging
Monitoring and logging changes that simplify diagnostics compared with the previous shared CloudWatch log streams.
- 04
Deployment and testing workflows
More consistent deployment through the Serverless Framework and Bitbucket Pipelines, with PHPUnit testing support.
- 05
Documented APIs
Swagger documentation for the integration, event-management and OpenADR endpoints.
Product change
What changed for the product team
The Enersponse DRMS kept its AWS serverless runtime but gained reworked OpenADR 2.0a/2.0b event handling, restructured event orchestration across VENs, improved monitoring and logging, documented APIs and more consistent deployment and testing workflows. The work was delivered with LLM-assisted development, which made the team about 20% more efficient.
For a team running a protocol-heavy energy platform that is outgrowing its first architecture, the case shows how to review and extend a live serverless system, covering protocol handling, event orchestration, logging and pipelines, without rebuilding it. It also shows how an AI-native engineering team uses LLM assistance on a live platform without loosening review and testing.
- The DRMS handles OpenADR 2.0a and 2.0b VEN registration and event lifecycles on its existing AWS serverless architecture.
- Platform teams have documented APIs, improved monitoring and logging, and more consistent deployment and testing workflows.
- Measured efficiency gain from LLM-assisted engineering
- +20 % During the engagement · Measured by Indeema across its engineering work on this project
Product evidence
A closer look at the product
Technology, in context
OpenADR 2.0a · OpenADR 2.0b · PHP · Python · MySQL (Amazon RDS) · AWS Lambda · Amazon SNS · Amazon CloudWatch · Amazon API Gateway · Serverless Framework · Bitbucket Pipelines · Docker · Swagger · PHPUnit · LLM coding assistants
A comparable product problem?
Enersponse demand-response platform
Bring the product context, the system that already exists and the engineering decision you need to make.