Frontend Architecture for a Multi-Product Platform

React/TypeScript platform and design system across 9+ products

Overview

Stockholm Exergi's Intelligy Solutions is a multi-product energy analytics platform – cloud services connecting 10,000+ properties for monitoring, control, and optimisation. I joined in 2018 as a UX/UI designer. Over the next seven years, my scope expanded from product design into full ownership of the frontend architecture across 9+ products.

I built what those teams now share: a React 18+/TypeScript monorepo, a 60+ component design system, and a type-safe API layer generated from OpenAPI specs. It became the foundation for every new frontend, and features ship roughly 3x faster on it.

The Challenge

The platform had successfully digitised thousands of district energy substations, but the software had grown organically. Engineering pain had accumulated:

• Multiple products on independent codebases – inconsistent UX, duplicated effort
• Legacy Django/Python stack made frontend iteration slow
• No shared component library, no design system
• API integration was brittle – each team hand-wrote clients against a shifting spec
• New apps started from scratch, re-solving the same problems

The Work (2018–2025)

My scope expanded steadily – from product design into frontend engineering, then architecture and enablement.

Architecture

Operations users needed to make decisions quickly on complex energy data. The platform had to surface context without forcing people to interpret raw numbers – consistently across every product in the suite. A few UX principles carried through from design into engineering:

• Progressive disclosure – summary first, details on demand
• Contextual comparison – data means nothing without reference
• Action-oriented – every insight connects to something users can do
• Consistent naming – shared language across products and field workflows

Everything below was built to support those principles across 9+ products, 8+ microservices, and multiple teams.

Design System (STEXUI)

A comprehensive component and theming system built with React, TypeScript, Radix UI primitives, Tailwind CSS, and CVA for type-safe variants. Sixty-plus components – from primitives to composite modules – standardising how measurements are formatted, how loading states render, and how optimistic updates behave, so the experience feels consistent everywhere.

Complex components built for real needs: data tables with TanStack integration, Mapbox-powered property maps, date range pickers with custom intervals, a Chart.js-based analytics module for custom datasets, and a composable sidebar system.

Type-Safe API Infrastructure

Connected 8+ microservices with generated TypeScript clients. OpenAPI spec → generated SDK → TanStack Query hooks → UI, with Zod validation at the boundary. API integration bugs went from a recurring problem to essentially zero.Read more: Contract-First APIs at Stockholm Exergi.

Shared Infrastructure

A monorepo with shared utilities for formatting, localization, and common data patterns. Reusable hooks and table tooling. Tooling standards kept packages, configs, and updates centralised. New apps inherited the full platform from day one.

No Handoffs

Our frontend team owned product design and engineering together. No translation layer between Figma and code, no disciplines to hand off between. Components were the spec.

When a pattern needed to change, the same people who designed it could ship it. When implementation forced a rethink, we rethought the design on the spot. The feedback loop stayed tight, and decisions stayed consistent from UX intent through to production.

Every handoff is lossy compression. Removing that layer is what made the architecture above possible to build – and keep coherent across 9+ products.

Results

Adoption: Unified stack across internal products – 4 migrated, 5 in pipeline at handover.

Velocity: New features shipped ~3x faster once teams adopted the shared component library and API tooling.

Quality: Hard-to-trace integration bugs became same-day fixes after type-safe API clients with Zod validation landed across all endpoints.

Onboarding: Developer ramp-up dropped from weeks to days – same stack, same patterns across all products.

Reusability: New applications inherited the full component library and tooling from day one.

Learnings

Contracts scale better than conventions.
Generated, type-safe clients eliminated an entire class of bugs that no amount of review could catch. Every service becomes predictable from the frontend's point of view.

Design systems are governance problems, not component problems.
Building a button is easy. Getting nine products to use the same button – and keep using it – is the real work.

Technical Summary

Stack: React 18, TypeScript, TanStack Query, TanStack Router, Radix UI, Tailwind CSS, OpenAPI, Zod, Figma, Vite, npm workspaces

Scope: 9+ internal operations products on a shared frontend platform and design system

See some of the patterns in action in the JOSUI design system monorepo case study and in josui – my open source design system inspired by some of the same principles.