Engineering

The case for slow software

We rewrote our rendering pipeline from scratch. The benchmarks told one story. Our users told us something else entirely.

Kei Nakamura June 12, 2026 11 min read

Last November, our performance dashboard lit up in amber. Page loads on the Spectra dashboard had crept from 320ms to 980ms over eight months, not catastrophic, but trending the wrong direction. The obvious fix was to rewrite the renderer. We had a prototype that compiled, and a VP of Engineering who wanted it shipped by Q1.

What the benchmarks missed

The new renderer was fast. Objectively, measurably, undeniably fast. Audit scores jumped from 72 to 96. Time to interactive dropped by 60%. Every page looked cleaner in the report. And then the support tickets started arriving.

Users don't perceive speed in milliseconds. They perceive speed in confidence — the feeling that the interface knows what they want before they ask.

Three weeks after launch, our NPS had dropped eleven points. Users described the new interface as jittery, unsettling, and hard to trust. We had optimized for the wrong variable: the old renderer moved at a pace that matched human expectation.