Every engineering team we talk to has the same complaint: builds are too slow. The instinct is almost always to reach for something new — a different bundler, a shinier CI provider, a rewrite in a faster language. We resisted that instinct, and over one quarter we halved our median build time without swapping out a single tool.
This is the story of how we did it, what we measured along the way, and the small but stubborn assumptions we had to unlearn. None of the individual changes were dramatic. Together, they took our pipeline from twenty-two minutes to just under eleven.
Start by measuring, not guessing
Our first mistake was believing we already knew where the time went. We assumed dependency installation was the bottleneck; the traces told a different story. Nearly forty percent of every build was spent recompiling packages whose inputs had not changed at all, because our cache keys were derived from a lockfile hash that churned far more often than the code did.
The slowest part of your build is almost never the part your team complains about. Instrument first, then argue.
Once we scoped cache keys to the actual source directories of each package, cache hit rates jumped from 31% to 87%. That single change bought us six minutes. The remaining gains came from running test shards in parallel, deferring artifact uploads until after the gate check, and deleting two legacy steps nobody could explain.
The lesson we keep returning to: the stack was never the problem. The pipeline around it was. Before you budget a quarter for a migration, spend a week reading your own traces — you may find the fastest tool you own is the one you already have.