Engineering

How we cut build times in half without changing the stack

Our builds had crept past nine minutes. Nobody decided that should happen; it just accumulated, one dependency and one extra step at a time, until the wait became part of the workflow. We pulled it back under five without rewriting a line of application code or swapping a single tool.

The temptation, when a pipeline feels slow, is to reach for something new. A faster bundler, a different language, a shinier cache. We resisted that. The stack was not the problem, and replacing it would have cost us weeks while introducing risks we did not understand yet. Instead we treated the build like any other system that had quietly degraded.

Start by measuring, not guessing

Before touching anything, we instrumented every stage and let it run for a week. The numbers were unkind to our assumptions. The step we were sure was the bottleneck accounted for less than a tenth of the total. The real cost lived in places nobody thought to look: redundant dependency installs, a test suite that re-built fixtures it already had, and a cache that was being invalidated on almost every run.

The slowest part of your build is almost never the part you complain about. It is the part you stopped noticing. - Dana Okoro

With the real picture in front of us, the fixes were small and boring. We pinned the cache key to the things that actually changed. We split the install so unchanged dependencies were restored instead of re-fetched. We let the test runner reuse its own artifacts. None of it was clever. All of it was measurable, and each change earned its place by moving a number we could see.

The build now sits comfortably under five minutes, and more importantly, we understand why. When it drifts again - and it will - we have the instrumentation to find the cause in an afternoon instead of arguing about it for a sprint. The stack never needed to change. We just needed to stop guessing.