How we cut build times in half without changing the stack

For months our continuous integration pipeline had been a quiet tax on the whole team. Pull requests sat amber for twenty minutes or more; context switched away and came back cold. We kept telling ourselves the fix would arrive with the next major framework upgrade. It never did.

What finally moved the needle was not a rewrite, a new language, or a flashy build tool. It was a disciplined pass over how we compiled, cached, and tested the code we already had. The stack stayed put. The clock did not.

Start by measuring, not guessing

Before we touched a single config file, we instrumented the pipeline end to end. Wall-clock times for install, compile, unit tests, and packaging were logged on every branch for two full weeks. The data was unkind but clarifying: dependency resolution and cold TypeScript compilation accounted for nearly seventy percent of the wait.

Half of our “slow build” problem was work we were repeating on every commit for no good reason.

With numbers in hand we ordered the backlog by minutes saved per hour of effort. Remote build caches, stricter workspace boundaries, and parallel test shards each earned a place. Speculative rewrites of greenfield modules did not. In six weeks average CI time fell from twenty-two minutes to just under eleven—without abandoning the toolchain the team already knew how to debug at 2 a.m.

The lesson we keep repeating is simple: treat build performance as a product surface. Measure it, ship small improvements, and resist the romance of starting over until the data insists you must.