How we cut build times in half without changing the stack

Our continuous integration pipeline had quietly grown into a bottleneck. What had started as a tidy three minute build crept past twelve, then fifteen, and on a bad afternoon it would flirt with twenty. Every pull request paid the tax, and the cost compounded across a team that ships dozens of times a day.

The instinct in moments like this is to reach for something new: a different bundler, a faster language for the hot paths, a wholesale migration to whatever the loudest blog post is recommending that month. We resisted. The stack was not the problem. The way we were using it was.

Start by measuring, not guessing

Before we changed a single line of configuration, we instrumented the build. We broke the pipeline into named stages and recorded how long each one took on every run for a week. The picture that emerged was not the one any of us would have guessed.

Roughly sixty percent of the wall-clock time was spent on work that had not changed between commits. We were reinstalling dependencies that were already cached, recompiling modules that no input had touched, and re-running an end to end suite that gated far more than it protected.

The fastest build is the one you never have to run. Everything after that is just arithmetic on the work that remains. Dana Okoro

Armed with real numbers, the fixes were almost boring. We made the dependency cache content-addressed so it actually hit. We turned on the compiler's incremental mode and persisted its state across runs. We split the test suite so the slow end to end checks ran only when the code they covered changed.

None of it required a rewrite. The bundler stayed. The language stayed. The CI provider stayed. We simply stopped asking the machine to redo work it had already finished. Median build time fell from just over fourteen minutes to a little under seven, and the worst case stopped being a coin flip.

The lesson we keep relearning is that performance work rewards patience over novelty. Measure first, change one thing, measure again. The stack you already have is usually faster than you think once you stop making it repeat itself.