Why Redline is getting heatmaps before A/B testing

Heatmaps are coming to Redline. A/B testing is not — not yet. I picked heatmaps on purpose, and the reason is boring in a good way.

Both features need the same hard part

Heatmaps and A/B testing share one dependency: a tracking script running on the client's site. That script is the genuinely hard, shared piece of work. It has to load fast, never block rendering, survive weird CSS and single-page-app routing, respect privacy, and not throw errors in someone else's console. Get that wrong and it doesn't matter what feature sits on top of it.

A/B testing needs one extra, riskier piece

A/B testing also needs a redirect server for variant assignment. That's the component most likely to break something on a live client site — or quietly cost me money while it sits there absorbing traffic. It's the part where a bad deploy doesn't just lose data, it loses a visitor.

So: script first, shipped as heatmaps

Build the script. Ship it as heatmaps. Learn what breaks in the real world — the caching quirks, the CSP headers, the sites that lazy-load half their DOM. Then reuse the same script for A/B testing once I actually trust it. Same foundation, half the blast radius.

The collector runs on its own

The event collector is its own isolated deployment. If it falls over, annotation and feedback keep working exactly as they do today. Redline's core job is getting client feedback out of email threads — nothing experimental gets to take that down.

It's also gated behind a flag on my own account until it's not embarrassing. I'd rather run it on my own sites for a few weeks than hand you a v1 that mangles a client page.

The takeaway

Ship the shared dependency as the lower-risk feature first. Learn from it in production. Then layer the risky feature on top of something you've already proven. Boring, in a good way.