Experiment: The hidden costs of waiting on slow build times

Measuring the real price of build waits

Hardware spend is the easiest compute cost for a business to justify pushing back on, whether it’s physical infrastructure, managed cloud instances, or SaaS-based resources. The recurring line item is visible every month, and the value of upgrading isn’t always obvious. Developers, for their part, will almost always ask for more powerful machines—not out of preference, but because faster builds mean more time writing code and fewer minutes staring at a progress bar.

What’s less clear is whether the higher price tag for beefier compute actually pays for itself when you factor in developer productivity. To get a concrete answer, I ran builds of a real project across GitHub’s newer larger hosted runners, comparing build duration and runner cost at every tier from 2 cores up to 64 cores. Then I compared those numbers against the average hourly cost of a US-based developer to see what a slow build actually costs a company.

The results make a strong case that cheap hardware is usually the more expensive option.

Build runtime versus compute cost

The test project was a Linux kernel compilation for Fedora 35 and 36 from my personal repository—the build needs a non-standard patch to support certain hardware. It’s a hobby project, but a long kernel build is a decent proxy for the kind of heavy compile workloads developers deal with professionally.

I ran the build twice at each compute tier and averaged the runtimes. The raw results:

Two scenarios matter here. In the first, a developer waits idly for the build to finish and does nothing else. In the second, they context-switch to another task and pay the mental cost of recovering focus. Both situations drain productivity, but in different ways.

Scenario one: developers wait it out

If a developer simply watches the build run, the business loses that time outright. StackOverflow’s 2022 Developer Survey puts the average total cost of a US developer at roughly $150,000 per year including benefits and taxes, which is about $75 per hour. A one-hour build wait therefore costs the company $75 in salary with nothing produced in return.

Factoring in that hourly rate against the build runtimes at each tier gives this picture:

The pattern is predictable—more cores, faster builds—but the dollar figures are stark. The amount a business effectively pays its developers to wait far exceeds what it would spend on faster runners.

The takeaway: Hardware costs are a rounding error compared to engineering salaries. Giving a team more CPU power directly converts waiting time into development time, and the benefit compounds as team size grows.

Scenario two: the hidden tax of context switching

A more realistic alternative is that developers don’t sit idle—they shift to another task while the build runs. That introduces a different penalty. Research from Gloria Mark at the University of California, Irvine has shown it can take about 23 minutes to fully re-engage with the original task after an interruption. Given that development work is often deep and detail-heavy, I used a round one hour as the recovery estimate for my analysis.

With that assumption added in:

Interestingly, once you accept a fixed context-switching penalty regardless of build length, the delta between compute tiers narrows—waiting for a 64-core build to finish versus a 4-core build has a similar productivity cost if you switch tasks anyway. What doesn’t change is the overall conclusion: labor remains far more expensive than compute, even at the highest-tier runner pricing.

Not everyone needs a full hour to recover focus. Cornell research suggests some developers are back on task in as little as ten minutes, so I also modeled 30-minute and 15-minute recovery windows:

Plotting all the data together shows the full cost landscape for a single developer:

With an average developer hour priced at $75, even the most expensive runner tier—64 cores and 256GB of RAM at $15 per hour—is only a fifth of the cost of one idle developer hour. As salaries climb, hardware prices hold steady, and build durations shrink, the economic argument for faster compute only strengthens.

The verdict on slower builds

The math is consistent: paying more for stronger hardware is cheaper—and less frustrating for the team—than letting developers cool their heels or juggle tasks around slow builds. Spending an extra $4–5 on a faster build run saves roughly $40 per build for an individual developer, and over $200 per build for a team of five, before counting the productivity loss from context switching.

Those extra dollars do scale up across many builds, but so does the compounded cost of lost engineering time. While this experiment used GitHub’s larger hosted runners as the test bed, the conclusion transfers directly to self-hosted machines and cloud instances. The upfront premium for CPU capacity is an investment that pays back in engineer-hours—and the engineering team gets to keep its momentum too.