Command Dashboard

Overview

The Keyholding Company provides security services to more than 6,000 enterprise clients. Incident information was fragmented across separate sections of the existing platform - tracking what had been raised, what was progressing, and what hadn't been actioned meant searching and filtering across multiple areas. I built the frontend of Command, a dashboard that consolidates that activity into one live view, carrying around 1,000 incident messages a day.

Decisions

WebSockets, with the failure modes written down

Incident updates needed to reach the screen without a refresh, so they are pushed over WebSockets. I wrote the ADR for the approach, and most of it deals with the parts that go wrong: how the client reconnects when a connection drops, and how the socket is authenticated.

Agreeing the types before the API existed

The dashboard was built alongside its backend. Rather than wait, we agreed shared TypeScript types for the API up front, and I built the frontend against that contract - data fetching with TanStack Query and the live views were never blocked on endpoints that didn't exist yet.

Piloting behind a flag

Command shipped to EY, the first enterprise client, behind a GrowthBook feature flag. The pilot was explicitly meant to surface improvements before a wider rollout, and the flag kept it scoped to one client - and switchable off without a deploy - while that happened. The frontend is tested end-to-end with Playwright.

Outcome

What used to be a search-and-filter exercise across separate platform sections became one consolidated live view: raised, in-progress, and un-actioned incidents in a single place, updating as messages arrive. It shipped to the pilot client roughly three months after the WebSocket ADR was written, on a type contract agreed before the API existed.