Case 01

Fintech / 2026

Ledgerline

Sixty frames, every frame

A trading dashboard that had grown for nine years and could no longer render a full order book without dropping frames. We rebuilt it from the data model up.

Client
Ledgerline B.V.
Year
2025 — 2026
Teams
Design (3) · Engineering (4)
Scope
Research, design system, charting layer, front-end rebuild
Stack
TypeScript · WebGL · Rust (WASM) · Vite
Result
p95 frame time 41ms → 9ms

Step 01 — Read

The problem was not the chart

Two weeks in the support queue told us most complaints were not about speed at all — they were about trust. Traders could not tell whether a stale number was stale. We spent the rest of the pass on a staleness model, and only then on the renderer.

Step 02 — Draft

Drawn at real density

Every direction was built in the browser against a live feed. A comp with twelve rows lies; the real screen has four hundred, and the type had to survive that.

Step 03 — Build

A renderer that budgets

The charting layer moved to WebGL with an explicit frame budget: anything that cannot draw in 6ms degrades on purpose, visibly, so the interface never silently lies about how current it is.

Step 04 — Again

Four weeks later

We came back with the numbers. Three of our favourite decisions were wrong, and we removed them. That is what the fourth pass is for, and it is why it is in the contract.

9ms

p95 frame time, down from 41ms

-34%

Support tickets tagged "wrong number"

1

Design system, shared with three other products

Next

Back to the index