Engineering

How we cut build times in half without changing the stack

Our continuous integration pipeline had quietly grown into a bottleneck. What began as a tidy two-minute build crept past the ten-minute mark, and every engineer felt the drag of waiting for green checkmarks before they could merge. The instinct on the team was to reach for a shiny new toolchain, but we resisted. The stack was not the problem. The way we used it was.

Over a single sprint we brought the median build down from just under eleven minutes to a little over five, with no migration, no rewrite, and no new vendor. The work was unglamorous: profiling, caching, and a handful of small changes that compounded. Here is what actually moved the needle.

Start by measuring, not guessing

The first thing we did was stop speculating. We instrumented every stage of the pipeline and let a week of real builds pile up before we touched a single line of configuration. The data was humbling. The step we assumed was slow accounted for barely eight percent of the total, while dependency installation, which nobody had thought about in months, ate nearly a third of every run.

If you cannot point at the slowest stage with a number next to it, you are optimising a feeling, not a pipeline.

With a clear picture in hand, the fixes chose themselves. We warmed the dependency cache between runs, parallelised the test suites that had no business running in sequence, and pruned a build artifact that was being regenerated on every push for no reason at all. None of these were clever. All of them were obvious once we could see them.

The lesson held long after the numbers stopped improving. Speed came not from a better tool but from understanding the one we already had. The next time a system feels slow, resist the urge to replace it. Measure it first, and let the evidence tell you where the time is really going.