All work
Web · Data

Helios — Energy Analytics Platform

Real-time dashboard processing millions of meter readings, with forecasting and anomaly alerts for grid operators.

Next.jsPythonAWS
He
Timeline
7 months to first release
Team
2 backend · 2 frontend · 1 data · 1 designer
Surface
Web dashboard + internal API
Scale
~2.4M meters, 15-minute intervals
01The challenge

Helios sells analytics to regional grid operators. The data was already flowing in — the problem was that nobody could act on it until the next morning.

Sector
Energy · Grid operations
Region
Northern Europe
Engagement
Platform build + ongoing partnership

Smart meters across the network report every 15 minutes. That is a few hundred million readings a month, and it was all being swept into a nightly batch job that produced PDF reports. By the time an operator saw that a substation had been drifting out of tolerance, the drift was twelve to thirty-six hours old.

Analysts had worked around it the way analysts do: exporting CSVs and rebuilding the same pivot tables in Excel every week. Three people were spending most of a day each on work that should have been a page load. Meanwhile the sales team was losing deals to competitors who could demo a live screen.

The constraint that shaped everything: this is regulated infrastructure. Readings are auditable, retention rules are fixed, and a dashboard that shows a wrong number is worse than a dashboard that shows nothing. We needed speed without loosening correctness.

02What we built

How the work was actually sequenced

  1. Streaming ingestion in front of the batch job

    Rather than a risky big-bang replacement, we put a streaming path alongside the existing nightly pipeline and ran both for six weeks. Readings land in a queue, are validated and normalised, then written to a time-series store partitioned by region and interval. The batch job stayed authoritative until the streaming path matched it reading-for-reading.

  2. Pre-aggregation, so the dashboard never scans raw data

    Operators look at rolling windows, not individual readings. We materialise hourly, daily and weekly rollups on write, which is what turned a multi-second query into a sub-100ms one. Raw readings stay queryable for audit and drill-down, just off the hot path.

  3. Forecasting and anomaly detection as separate services

    Load forecasting and anomaly detection have different failure modes and different retraining cadences, so they run as independent Python services. If the forecast model is down, alerts still fire; if anomaly scoring is degraded, the dashboard still loads. Every alert links back to the readings that triggered it.

  4. A dashboard built for a control room, not a demo

    Dense tables, keyboard navigation, no gratuitous animation, readable on the wall-mounted screens the operators actually use. Server-rendered with Next.js so first paint does not wait on a chart library, with live updates layered on after.

03Results
< 90sReading to dashboardpreviously a nightly batch
~2.4MMeters ingested15-minute intervals
3 days/wkAnalyst time returnedmanual CSV reporting retired
99.9%Ingestion uptimefirst 12 months post-launch
04Stack

Frontend

  • Next.js
  • TypeScript
  • Tailwind CSS

Backend & data

  • Python
  • FastAPI
  • PostgreSQL
  • TimescaleDB
  • Redis

Infrastructure

  • AWS
  • ECS
  • Kinesis
  • S3
  • CloudWatch
  • Terraform
Next case study

BrightLearn — Mobile Learning App

Mobile

Got something like this in mind?

Tell us what you're building. We'll come back within one business day with a clear plan and an honest estimate.

Start a Project