The case for slower software
Why we rewrote our fastest system — and shipped better software because of it
I spent two weeks last January staring at a performance dashboard that told me everything was fine. Our issue tracker loaded in 180 milliseconds. Our API responses averaged 45ms p99. Every metric we tracked was green. And yet, something felt fundamentally broken about how our team shipped software.
The speed trap
We had optimized for the wrong thing. Throughput — tickets closed per sprint, pull requests merged per week — had become our north star. But velocity without direction is just noise. The team was burning through tasks faster than ever, and the product was getting worse. Features shipped half-baked. Technical debt compounded silently beneath every release.
What would our workflow look like if we designed it from scratch, ignoring every convention we'd internalized over four years?
The rewrite began as a side project in March. Two engineers, no deadline, no sprint planning. We started by interviewing every team member — not about what was broken, but about what they wished existed.