One Product. Two Markets. No Software Team.
The client had built a wall-mounted home battery that could be installed by the homeowner without an electrician, without permits, and without rewiring. Plug it in, set it up with the app, and it starts managing your energy automatically. The hardware team understood the product well. What the company did not have was anyone to build the software.
The software requirement was more demanding than a typical consumer IoT product because the device had to operate at two distinct levels. At the consumer level, it needed a mobile app that guided homeowners through self-installation, paired with the device, displayed energy usage, managed charge and discharge schedules based on utility pricing, and controlled built-in features like LED lighting and Bluetooth speakers. At the grid level, the same fleet of devices needed to function as a coordinated distributed energy resource: utilities could partner with the company to dispatch devices for demand response, frequency control, load shaping, voltage support, and transmission investment deferral.
A single cloud platform had to serve both. That was the engineering problem Sequoia was brought in to solve.
Consumer App, Grid Control Engine, and Everything Between
Sequoia Applied Technologies is a Santa Clara software engineering firm that builds software products for technology companies in cleantech, life sciences, IoT, and enterprise software. The firm regularly serves as the software function for hardware companies that do not have one. This was a greenfield engagement, starting from no prior codebase.
The architecture decision came first. Two models were considered for how the device and the mobile app would communicate. One treated both as first-class endpoints on the IoT platform, communicating peer-to-peer through the cloud. The other used a standard layered model, where only the device connects to the IoT platform directly and the mobile app communicates via REST APIs. The layered approach was chosen. It kept the device and the app decoupled from each other, allowed each to evolve independently, and avoided the security exposure of distributing device credentials across consumer phones. That decision also made the utility-side fleet management cleaner: the cloud control engine could talk to devices without any dependency on what version of the app a consumer was running.
The consumer-facing mobile app was built as a cross-platform application for iOS and Android. Account setup used multi-factor authentication across email, SMS, and phone. A wizard-driven onboarding sequence guided the user through device registration, terms acceptance, energy monitor installation, safety sticker placement with photo capture for back-office review, and a cloud-orchestrated circuit breaker trip test before the device could activate. Once running, the app showed energy consumption data, let users set and adjust charge and discharge schedules, managed multiple devices across rooms or homes, and gave direct control over the lighting and Bluetooth speaker. Because the devices are scalable, a single homeowner could manage several units from the same app interface.
The energy scheduling logic ran server-side. The platform queried utility pricing data and used it to determine when the battery should pull from the grid versus supply the home. Cheap electricity in: the battery charges. Price rises: it discharges. Users could also set manual schedules or configure backup-only mode. The pricing rules were data-driven configuration, so onboarding a new utility partner or adjusting regional tariffs required no code change on the app or the device.
The utility-facing cloud control engine sat above that same device layer. Utility partners could configure demand response programs, set dispatch rules for their subscriber fleet, enable time-of-use pricing models with consumer incentives, and manage the fleet as a virtual power plant for services including frequency control, load shaping, T&D investment deferral, and voltage support. The platform was designed with configurable modular functionality so different utility partners could activate the service mix relevant to their operating context. A white-label option allowed utilities to present the consumer app under their own brand.
The cloud layer handled telemetry from each device in the fleet, stored in a NoSQL database, with user and account data held separately in a relational database. Push notifications, email, and SMS gateways ran from the same platform. Over-the-air firmware updates gave the team a path to update device behavior across the entire installed base without physical access. An admin portal supported back-office operations including manual review of safety sticker photos and fleet monitoring.
One architectural note: local device controls like lighting and Bluetooth volume ran over Bluetooth Low Energy directly between the phone and the device, bypassing the cloud for those interactions. The cloud round-trip latency would have made those controls feel unresponsive. The decoupled architecture did not preclude direct local communication where it genuinely mattered.
How the Platform Served Consumers and Utilities from a Single Stack
The system is organized in three layers. The device communicates up to the cloud platform. The consumer app and the utility control engine both communicate with the same cloud platform via separate interfaces. The device and app do not talk directly except for local Bluetooth functions.
Cross-platform app covering account setup with multi-factor authentication, regulatory onboarding wizard, energy consumption and savings display, charge and discharge scheduling with utility pricing integration, multi-device management across locations, and direct controls for LED lighting and Bluetooth speaker. Scalable to manage multiple storage units per household.
Fleet management platform for utility and energy retailer partners. Configurable demand response programs, virtual power plant dispatch, time-of-use and dynamic pricing model support, frequency control services, load shaping, T&D investment deferral, and voltage support. Modular functionality switchable per utility partner. White-label consumer app option included.
Device communicates with cloud via embedded endpoint SDK over TCP. Cloud stores device telemetry in NoSQL and user data in relational database. Handles push notifications, SMS, email, and over-the-air firmware updates across the full installed fleet. Admin portal for back-office fleet monitoring and safety verification. BLE for local consumer device control.
Multi-stage sequence enforced by both app and cloud: account creation, SMS-verified registration, terms acceptance, energy monitor setup, safety sticker photo capture for manual back-office review, cloud-orchestrated circuit breaker trip test to confirm correct wiring, and device activation. Each stage must complete before the next unlocks. Process state is persisted in cloud so installation can resume after interruptions.
The layered architecture also has an operational benefit for the utility side: the cloud control engine can dispatch devices and receive telemetry without any dependency on the consumer app. A utility running a demand response event does not need consumers to have the app open or updated. The device responds to cloud commands directly.
Common Questions About IoT Software for Energy Storage Products
Can Sequoia build IoT software that serves both consumers and utility-grade grid operations?
Yes. This engagement is a direct example. The client's hardware served consumers who self-installed the device at home, and the same device fleet served as a distributed energy resource for utility partners running virtual power plant, demand response, and frequency control programs. Sequoia designed the cloud architecture so both sides ran from a single platform, with the consumer app and the utility control engine communicating through separate interfaces to the same device layer.
What is a virtual power plant and what software does it require?
A virtual power plant aggregates distributed energy resources, in this case home batteries installed across many households, and allows a utility or energy retailer to dispatch them as a coordinated grid asset. The software needs a cloud control engine that can communicate with each device in the fleet, issue charge and discharge commands based on grid conditions, track device state in real time, and present configurable controls to utility operators. It also has to coexist with the consumer app on the same device without the utility layer interfering with what the homeowner expects. That coexistence is an architecture problem, not just a features problem.
What grid services can utilities offer through a distributed home battery fleet?
With software-controlled home batteries, utilities can run demand response programs, provide frequency control and load shaping services, defer transmission and distribution investment, support voltage regulation, and relieve network congestion. Because these devices install at the consumer site without permits or construction, the addressable fleet includes renters and apartment dwellers, not just homeowners with solar. That matters for utilities trying to reach high-density housing for grid flexibility programs.
How does the energy optimization work with utility time-of-use pricing?
The battery stores energy when utility rates are low and discharges to the home when rates rise, automatically. The scheduling logic runs server-side and queries real-time pricing data. Users can also configure manual schedules or set the device to backup-only mode through the app. Because the pricing rules are data-driven configuration rather than hardcoded logic, adding a new utility or adjusting regional tariffs requires no app or firmware release.
What does the regulatory onboarding for a self-install home battery involve?
Installing a home battery without a licensed electrician means the software has to enforce the safety verification steps that would otherwise be handled during a permitted installation. In this product the onboarding wizard covered account creation with multi-factor authentication, SMS-verified device registration, terms acceptance, energy monitor installation guidance, safety sticker placement with photo upload for back-office review, a cloud-orchestrated circuit breaker trip test to confirm correct wiring, and device activation. App and cloud both enforce each stage before the next can proceed.
What cleantech and IoT software development work does Sequoia Applied Technologies do?
Sequoia Applied Technologies is a Santa Clara, California software engineering firm that builds software products for companies in cleantech, life sciences, IoT, embedded systems, and enterprise software. For hardware companies, Sequoia commonly serves as the full software engineering function: mobile development, cloud and IoT architecture, device management, and production delivery. Engagements include full greenfield builds, specific layer work on existing products, and projects where the software has to serve multiple markets from a single platform.