My Favorite Feature as a TPM

I spent years as a technical program manager at a trading platform. The feature I liked working on most was market replay. Capture a live order book, play it back later, tick by tick. Traders used it to review their sessions and practice reading order flow without risking money.

We were rewriting the entire platform at the same time. Replay had to play nice with every other subsystem. Charting, indicators, strategies, multi-instrument sync, session management. Every release was whack-a-mole. Fix a replay freeze, break something in the indicator pipeline. Get tick-level fidelity working, performance tanks with multiple charts open.

That was the hardest part of the TPM job. Not because replay was hard on its own, but because it had to be a well-behaved citizen inside a massive desktop application. Every feature I wanted to ship had a good reason to get deferred.

Per-event visual updates? Too expensive when you’re rendering twelve chart panels. Portable session files? Doesn’t fit the proprietary data pipeline. Deterministic state reconstruction? Nice to have, but the strategy engine needs its own event model.

Always something else was more important.

Soon after the release candidate, I left due to having kids. After consulting in tech for a few years in Seattle, I spent a few years as a stay-at-home dad, which is its own kind of program management. The difference is that the stakeholders cry when they don’t get what they want, and the sprint retrospective is more like a hostage negotiation we call “bedtime”.

I never stopped thinking about what that feature would look like if you ripped it out of the monolith and let it stand on its own.

The constraints that made it hard were all about coexistence. If replay is the whole product, most of them disappear. You don’t have to negotiate with the charting team about rendering budgets. You don’t have to route events through someone else’s strategy engine. You can make the session format portable because there is no proprietary pipeline to break.

After sitting on this concept for many years, I finally built it. I called it Matchstick Replay. The engine ingests Level 2 order book data from Kraken’s public WebSocket and replays it deterministically. You can scrub through sessions at multiple speeds — forward and backward. Same state at the same timestamp, every time. Every book change shows up as it happened, not bundled into one-second snapshots.

It runs in a browser. No download, no install, no account. Prices and sizes are stored as exact decimals — no IEEE float drift. You can export a session as JSON with full provenance: source, timestamps, bookmarks, and the complete event history.

It does not do execution simulation, and there are no indicator overlays. The data pipeline is lean and only uses crypto data for now. Those are real gaps, and I know they matter.

There is a free demo with a built-in BTC/USD session at replay.matchstick.trading. You can scrub through it right now.

I mostly want to talk to a few people about what they would actually replay and why.

Building a product as a side project while parenting full-time has taught me something I did not learn as a PM. When you have two hours a day and no team, every feature decision is a real trade-off. There is no sprint to push it to. There is no other team to hand it off to. You build it or it doesn’t exist.

The features that survived are the ones I would have fought for in every roadmap meeting and lost.