How we cut build times in half without changing the stack

For months, every build felt like a small gamble. The stack was stable; the pipeline was not. Once we started timing each stage with the same discipline we used for releases, the bottlenecks stopped hiding.

The first surprise was that our slowest runs were not dominated by compilation. They were dominated by repeated setup: fetching the same packages, rerunning the same checks, and serializing work that could have happened in parallel.

We treated the build like a product. That meant a visible budget, a clear owner for every minute, and a rule that no change could ship unless we could explain its cost.

Start by measuring, not guessing

Measurement replaced folklore. A simple dashboard showed where time accumulated, and the team stopped arguing about abstractions. We could see, in one glance, which changes paid off and which were simply moving the delay around.

If you can’t point to the slow step, you’re not ready to optimize.

From there, the wins were almost boring: move expensive checks earlier, reuse intermediate assets, trim a few overzealous dependencies, and stop doing the same work twice. None of it required a rewrite, and none of it asked engineers to relearn the tools they already trusted.