All notes
·1 min read

Real-time data, from trading floors to live sport

Real-timeWebSocketData vizUX

A lot of my work comes back to the same challenge: a firehose of live data, and a human who needs to make a decision from it right now. Two projects show the two ends of that spectrum.

Trading floors — TotalEnergies

At TOTSA I built a mission-critical reporting application for TotalEnergies' global oil and refined-products trading. The front end was React and TypeScript; the back end Django and FastAPI in Python, with real-time data flowing over WebSocket and Redis doing the caching and queueing. When your users are making strategic decisions at scale, latency and correctness aren't nice-to-haves — they're the whole product.

Live sport — European Broadcasting Union

At the EBU I designed and built a real-time sports-data proof of concept for football and the Olympics: processing live event streams, rendering intelligent dashboards, and feeding the data to an AI commentary generator. The stack was React and Node.js, with WebSocket, RabbitMQ, Redis and Socket.IO moving events around. I presented it directly to EBU leadership.

What carries across

  • Design for the glance. In both cases the person reading the screen has seconds, not minutes. Hierarchy and motion have to earn their place.
  • The pipeline is part of the UX. A dashboard is only as trustworthy as the freshness of the data behind it. Reliability upstream is what makes the interface believable.
  • Real-time is a system property, not a feature you bolt on. It touches the data model, the transport, the cache and the render path all at once.

The through-line — live data, made legible — is exactly what I bring to Ourse today.

Working on something with live data or a solo product?

I'm open to senior fullstack and UX/UI work, in Geneva and remotely.

Get in touch