CASE STUDY
An Energy Operator's Data Platform, Built for Real-Time and Scale
At a Glance
Energy and Utilities
Liechtenstein, Europe
Build, greenfield production system
BI & Analytics Modernization, Cloud, Data Platform Engineering
Completed
The Problem
Co4 Cloud is an energy management operator headquartered in Liechtenstein. The business runs energy and resource oversight programs for European facilities, tracking gas consumption, electricity usage, EV charging activity, and carbon emissions across multiple sites and occupant types.
The existing reporting infrastructure could not keep pace with what the business now needed. Data sat in separate sensor networks, metering systems, and disconnected reporting tools. Billing was reconciled manually. Carbon emissions reporting was retroactive rather than real-time, which is a problem when the customer is now asking for live sustainability evidence. Adding a new application or onboarding a new occupant required engineering work each time.
The brief, in short. Build a production-grade web platform that consolidates energy and resource management for a multi-tenant operator, supports real-time monitoring at sensor rate, and is modular enough to add new applications and new resource types without re-architecting.
What We Built
We designed and built a centralised energy management portal on a microservices and microfrontend architecture, with a few decisions made deliberately at the front of the engagement.
A Microservices Backend
Each functional domain (resource management, billing, notifications, user roles, sensor ingestion) runs as a separate service. New resource types can be added without touching the rest of the platform.A Microfrontend Shell
Built with Piral, so each application module loads independently and the platform can host partner applications inside the same shell. The in-platform application store works because of this layer.A Real-Time Data Layer
Sensor data from gas, electricity, EV charging, and CO2 sensors, including wireless LoRa sensors for indoor air-quality readings, flows into the platform through a FastAPI ingestion service. The data is exposed to the frontend through a Wundergraph backend-for-frontend layer over PostgreSQL and GraphQL. Live dashboards render against this data, not against batched reports.Role-Based Access from Day One
Owners, managers, customers, technicians, and operators each see and act on a different slice of the platform. The role model is built into the API layer, not bolted on at the UI.Sustainability as a First-Class Concern
Carbon emissions are tracked alongside resource usage rather than reported retroactively. Occupant comfort signals (temperature, humidity, CO2) are surfaced together so the operations team can balance energy spend against indoor air quality.Outcomes
The platform is live and running the operator's core business workflow. The outcomes captured during and after delivery.
- Centralised resource management. Gas, electricity, EV, and carbon data live in one operational view instead of four separate reporting tools.
- Real-time monitoring at sensor rate. Live data replaced batched daily and weekly reports.
- Self-service multi-tenant onboarding. New facilities, new occupants, and new applications are added through the platform itself, not through an engineering ticket.
- Modular forward compatibility. New resource types (water, district heating, future utilities) and new partner applications can be added by extending the microservice & microfrontend layers, not by rebuilding the platform.
- Role-segmented access at the API layer. Permissions hold up under audit and against an expanding set of user types.
Technology Stack
- Frontend : React, TypeScript, Piral microfrontend shell, Shoelace UI, charts and map libraries
- Backend : Python, FastAPI, Wundergraph BFF, PostgreSQL, GraphQL
- Architecture : Microservices, microfrontend, monorepo, web components
- Data and integration : Multi-source sensor and meter ingestion, wireless LoRa for indoor air-quality, role-based access enforcement, billing and notification subsystems
Practice Lines
This engagement drew from three of our four enterprise pillars.
- BI & Analytics Modernization. Real-time dashboards on a semantic data layer rather than batched reports.
- Cloud. Cloud-native microservices and microfrontend architecture with a modular path forward.
- Data Platform Engineering. Ingestion across heterogeneous sensor and meter sources into a single operational data layer.
What This Engagement Demonstrates
Three observations worth pulling out for buyers evaluating a platform of this shape.
First, modular architecture earns its place when the business model is multi-tenant. Co4 Cloud needs to onboard new facilities and new application partners continuously. The microservices and microfrontend decisions made at the front of the engagement are what make that operating model possible eighteen months later.
Second, real-time is a posture, not a feature. We did not retrofit a live data layer onto a batch system. The platform was designed for sensor-rate data from week one, which is why the dashboards render against current values and not against last night's export.
Third, role-based access at the API layer is the only model that scales. A growing operator with owners, managers, technicians, and customers cannot run on UI-level permissions. We built the role model into the data layer and the API contract, which is what holds up when the org chart expands.
Talk to Us About a Platform of This Shape
If you are scoping a multi-tenant operational platform with real-time data and modular onboarding, we can map our depth to your need in a 30-minute scoping call.