Problem
Co4 Cloud needed a production-grade web platform for gas, electricity, EV charging, carbon emissions, billing, and multi-tenant resource oversight. Data lived across sensor networks, metering systems, and reporting tools. Adding facilities, occupants, or resource types required engineering instead of configuration.
Constraints
Serve distinct user populations, owners, managers, customers, technicians, operators, with different access; ingest sensor data at sensor rate without losing real-time fidelity; onboard new tenants and resource types without a development cycle for each.
What ViitorCloud shipped
A centralized energy management portal on a microservices backend plus a Piral microfrontend shell. Sensor data through FastAPI into PostgreSQL and GraphQL-backed views. Role-based access control at the API layer across all five populations.
Architecture and delivery approach
Microservices separate ingestion, operational data, and tenant management for independent scaling. The Piral shell lets new modules and partner apps plug in without a rebuild. FastAPI ingestion, PostgreSQL operational state, GraphQL views. Access control lives at the API layer.
Outcome
The platform centralizes resource management, provides real-time monitoring at sensor rate, supports self-service multi-tenant onboarding, and offers a modular path for new resource types and partner applications.
What buyers should learn
A real-time multi-tenant platform is an architecture decision before a feature decision. Microservices plus a microfrontend shell up front makes self-service onboarding a configuration task later. API-layer access control keeps a multi-population platform defensible as it grows.
Building a platform that has to survive scale?
A senior practitioner will map the architecture decisions before the feature decisions.