How we cut build times in half without changing the stack

Slow builds are a tax on everything. They stretch the feedback loop, blunt focus, and quietly push people toward batching changes that should have shipped on their own. We spent a quarter convinced the only fix was a bigger rewrite or a new toolchain. It turned out the answer was much closer to home.

Over six weeks we brought our median CI build from just under eleven minutes down to a little over five, with no change to the languages, frameworks, or core libraries we already ran. The wins were unglamorous: caching the right things, splitting the work that could run in parallel, and deleting steps that no longer earned their place.

Start by measuring, not guessing

The first instinct is always to optimise the thing that feels slow. That instinct is usually wrong. We added simple timing around every phase of the pipeline and let it run for a week before touching anything. The data was blunt: two stages we never thought about accounted for more than half the wall-clock time.

If you cannot point at a number, you are not optimising - you are guessing with extra steps.

With the real cost centres named, the fixes almost suggested themselves. Dependency installation was repeating work that a warm cache could have skipped entirely. The test suite ran as one long serial block when most of it had no shared state at all. Neither problem needed a new tool to solve - only the discipline to look before reaching for one.

The lesson we keep relearning is that speed is rarely a single bottleneck waiting to be discovered. It is a pile of small, reasonable decisions that quietly compound. Measure honestly, remove what no longer pays its way, and the stack you already have usually has more headroom than you think.