The State of CI/CD for Scaleups 2026

Why CI cost explodes past roughly fifty engineers, when the first platform team forms, and how to bend the build-time curve before it bends the budget.

Executive summary

The scaleup is where CI quietly stops being free. Below roughly fifty engineers a pipeline is cheap, fast, and nobody owns it; it sits in the background, paid for out of a cloud bill nobody scrutinizes, and it does its job without anyone thinking about it. Above that line three curves bend upward at once: the number of merges per day, the size of the codebase each merge must build and test, and the matrix of platforms and services that each change touches. CI minutes do not grow linearly with headcount, they compound.

Our analysis models that compounding at roughly a 4.2x growth in CI minutes as a codebase scales past the fifty-engineer mark, driven mostly by build-time growth and merge frequency rather than headcount alone. That number is the single most important thing for a scaleup leader to internalize, because it contradicts the natural assumption that CI cost tracks team size. It does not. A team that doubles from fifty to a hundred engineers does not double its CI bill; it grows it several times over, because each new engineer merges into a larger codebase more often.

This is the moment a scaleup forms its first platform team, almost always in response to a CI bill and a build-time complaint rather than a strategy. The pattern is so consistent it is nearly a law: somewhere between fifty and a hundred engineers, a cost spike or a developer revolt over pipeline slowness creates the political will to staff people whose job is the pipeline. Recognizing the inflection in advance lets a scaleup invest in the runner layer before the fire rather than during it.

This report quantifies the cost-growth curve, the build-time curve underneath it, and the composition of the scaleup CI bill, then locates where managed runners hit break-even relative to the cost of a platform team. The recurring finding is that a large share of scaleup CI spend is not useful work at all; it is idle capacity, uncached recomputation, and re-runs from mechanical failures, which is precisely the portion a better runner layer reclaims without anyone changing how they write code.

The throughline: scaleups do not have a CI problem at fifty engineers, they have a CI problem that started at fifty and became unignorable at a hundred. The teams that act during the quiet phase, when the curve is bending but the bill is still small, bend the curve cheaply. The teams that wait until the bill forces a platform team pay for the same fix under pressure, after the cost has already compounded.

CI minutes grow roughly 4.2x as a codebase scales past fifty engineers

The headline of the scaleup CI story is non-linearity. Our model puts CI-minute growth at roughly 4.2x as a codebase crosses the fifty-engineer threshold, and the reason is that the cost drivers multiply rather than add. More engineers means more merges per day. A larger codebase means each merge builds and tests more. A broadening service and platform matrix means each merge fans out across more jobs. Three multiplying factors produce a curve that climbs far faster than headcount.

The per-engineer minute chart shows the compounding directly. Monthly CI minutes per engineer rise from a few hundred at small scale to over a thousand in the fifty-to-hundred band and higher still beyond it. This is the crucial point: it is not just that there are more engineers, it is that each engineer individually consumes more CI minutes as the codebase around them grows. The numerator and the denominator both increase, and the per-engineer figure climbs anyway.

Budgeting CI linearly against headcount is the single most common scaleup forecasting error, and it is always an underestimate. A finance model that projects next year's CI cost by multiplying this year's cost by the headcount growth rate will be wrong on the low side every time, because it misses the codebase-growth and matrix-fan-out terms entirely. The first step to controlling the curve is forecasting it correctly, which means modeling it as compounding rather than linear.

• CI minutes grow about 4.2x across the fifty-engineer threshold, driven by merges, codebase size, and matrix fan-out multiplying together.
• Per-engineer minute consumption rises with codebase size, so the per-head figure climbs even as headcount grows.
• Linear, headcount-based CI forecasting is the most common scaleup budgeting error and always underestimates.

Build time, not test count, is what teams actually feel

Engineers complain about the pipeline when it is slow, and they experience slowness as wall-clock time, not as a count of tests. Once parallelism is exhausted, pipeline slowness tracks codebase size far more than test count, because the uncached build and compile stage becomes the long pole. A team can shard its tests across a hundred runners and still wait on a single sequential build that has to compile a codebase that grows every month.

The build-time chart shows the curve steepening with codebase size: from single-digit minutes on a small codebase to dozens of minutes on a very large one. This is the number developers actually feel, multiple times a day, every time they push. It sets the tempo of the whole team. When the pipeline takes half an hour, engineers batch their changes, push less often, and lose the fast feedback loop that made the team productive when it was small.

The implication for where to spend effort is sharp. Caching and incremental builds beat simply adding runners, because a bigger runner makes a slow build slightly less slow while a warm cache makes it disappear. Restoring an unchanged build output is near-instant; recompiling it on a faster core is still recompiling it. The teams that keep their pipelines fast as they scale do it by doing less work, through caching and affected-target builds, not by buying their way through more of the same work.

• Once parallelism is exhausted, the uncached build and compile stage is the long pole, and it tracks codebase size.
• A bigger runner makes a slow build slightly faster; a warm cache makes it disappear.
• Slow pipelines push engineers toward large batches, which erodes the fast-feedback loop that made the team productive when small.

The platform team forms in response to the CI bill

For most scaleups the first platform or developer-productivity team is created somewhere between fifty and a hundred engineers, and the triggering event is almost always a CI cost spike or a build-time revolt rather than a deliberate org plan. The pattern is reactive by nature: nobody owns the pipeline while it is cheap and fast, so nobody is watching when it starts to compound, and the problem becomes visible only once it is already painful.

That team's first mandate is reliably the same: get the CI bill and the pipeline duration under control. They arrive to find a pipeline that grew organically, with little caching, oversized runners, a matrix that expanded without pruning, and a pile of flaky tests nobody had time to fix. Their first quarters are spent retrofitting the hygiene, the caching, the right-sizing, the impact analysis, that would have been far cheaper to build in earlier.

Recognizing the inflection early changes the economics entirely. A scaleup that knows the fifty-engineer line is coming can invest in the runner layer and the caching discipline before the fire, when the changes are small and uncontested, rather than during it, when they are urgent and expensive. The CI curve is one of the few scaling problems a team can see coming with near-certainty, which makes failing to prepare for it a planning failure rather than a surprise.

Idle and uncached compute is the reclaimable third of the bill

A large share of scaleup CI spend is not useful work, and the spend chart makes the composition explicit. Idle and queued runner capacity, re-runs from flaky failures, and uncached build steps together account for a meaningful slice of the bill that does not move the product forward at all. The uncached build and compile stage alone is the largest single category, and it is the most directly reclaimable, because the work it pays for was already done on a previous run.

These categories share a property: they are mechanical waste, not fundamental cost. Idle capacity is the gap between a fixed fleet and spiky demand. Re-runs from flaky failures are recovery from transient blips that a clean retry fixes. Uncached recomputation is paying again for an unchanged artifact. None of them is intrinsic to validating the code; all of them are addressable without touching a single test or rewriting any application logic.

This is the portion managed runners reclaim directly. They scale to demand instead of idling, so the idle slice shrinks. They self-heal transient failures instead of re-running them, so the flaky-rerun slice shrinks. And paired with proper caching, the uncached recomputation slice shrinks too. The reclaimable third of the scaleup bill is reclaimable precisely because it is mechanical, which is also why it can be removed by changing the runner layer rather than the codebase.

• Idle/queued capacity, flaky re-runs, and uncached builds are mechanical waste, not fundamental cost.
• The uncached build stage is the single largest category and the most directly reclaimable, since the work was already done.
• Managed runners reclaim this third by scaling to demand and self-healing, with no change to tests or application code.

Managed runners hit break-even before a platform team pays for itself

Self-hosting runners looks cheaper per minute until a scaleup prices in the parts the spreadsheet leaves out. The comparison usually pits a raw instance rate against a hosted per-minute rate and concludes the fleet is cheaper. It omits idle compute, the gap between a fleet sized for peak and demand that is mostly off-peak, and it omits the platform-engineering time to scale, patch, harden, and clean up that fleet continuously.

Once both are priced in, the math changes. At GitHub-hosted Linux rates of $0.008 per minute against a managed modeled rate of $0.0025 per minute, managed runners capture roughly 69% of compute spend with zero fleet operations. The per-minute saving is real on its own, but the operational saving is what dominates for a scaleup, because the engineering time a self-hosted fleet consumes is the same scarce time the platform team was hired to spend on higher-leverage work.

For a scaleup that has not yet fully staffed a platform team, the break-even lands before the headcount to run runners in-house can justify itself. This is the timing insight that matters: the moment a scaleup feels its CI bill is also the moment before it has the people to manage a fleet, which means the managed option is favored exactly when the team is least equipped to choose the self-hosted one. Waiting until a platform team exists to evaluate runners gets the sequence backwards.

The matrix grows by accretion and is rarely pruned

Scaleup CI matrices expand the way most configuration expands: by accretion. A new platform target gets added when a customer asks for it, a new operating system leg appears when someone ships a desktop build, an extra version of a runtime is pinned to support a lingering integration. Each addition is individually reasonable, and almost none of them are ever removed, because removing a matrix leg requires someone to prove it is safe to remove, and nobody is assigned that job.

The spend chart shows the macOS and Windows matrix legs as a distinct slice, and on hosted runners those legs are disproportionately expensive because non-Linux minutes cost a multiple of Linux minutes. A matrix that grew by accretion frequently runs expensive operating systems for work that is entirely OS-agnostic, linting, unit tests, dependency resolution, that would pass identically on Linux. The expensive runners end up doing cheap, duplicated work.

Pruning the matrix is one of the cleaner wins available to a scaleup's first platform team. Pushing OS-agnostic work onto Linux and reserving the expensive operating systems for genuinely platform-specific legs, signing, packaging, platform UI tests, cuts the non-Linux spend without losing any coverage. The platform-specific surface is almost always much smaller than the matrix that grew up around it, so the pruning reclaims real money the moment someone is finally assigned to look.

Caching is the lever that decouples cost from codebase size

The deepest structural fix for the scaleup CI curve is to break the link between cost and codebase size, and caching is the primary lever that does it. Without caching, every run pays in proportion to the size of the repository: the whole thing builds, the whole suite runs, regardless of how small the change was. With effective caching and affected-target analysis, a run pays in proportion to the size of the change, which is what restores sane economics as the codebase grows.

This reframes the build-time and spend curves from inevitable to optional. The reason CI minutes compound past fifty engineers is largely that uncached pipelines rebuild and retest far more than each change actually touched. A one-line change in a large monorepo should not pay for a full-repository validation, and with affected-target detection it does not. The cost driver moves from the size of the codebase back to the size of the diff, which is where it belongs.

Caching is conceptually simple and operationally finicky, which is why so many scaleups do it badly or not at all and then wonder why their bill compounds. Keys scoped too loosely serve stale content; keys scoped too tightly never hit. The teams that win treat cache keys as a first-class part of the pipeline, scoped to lockfiles and toolchain versions, and they monitor hit rates the way they monitor test coverage. Of every lever in this report, caching has the best ratio of payoff to effort for a scaling codebase, and it requires no change to application code.

Recommendations

Forecast CI as a compounding curve, not a linear one

Model CI cost against codebase growth and merge frequency, not just headcount, because the drivers multiply. A headcount-linear forecast underestimates every time. Knowing the fifty-engineer inflection is coming lets you invest in caching and the runner layer before the fire rather than during it.

Cache aggressively and make CI pay for the change, not the repo

Adopt affected-target builds and dependency and build caching, with monitored hit rates, so a one-line change does not pay for a full-repository validation. This is the single most effective brake on the scaleup cost curve, and it decouples cost from codebase size without touching application code.

Reclaim the mechanical third of the bill before adding capacity

Idle/queued capacity, flaky re-runs, and uncached recomputation are mechanical waste, not fundamental cost. Scale runners to demand, self-heal transient failures, and cache unchanged work to reclaim that slice, rather than buying bigger runners that pay full price for the same waste faster.

Prune the matrix and shift OS-agnostic work to Linux

Matrices grow by accretion and are rarely pruned. Push linting, unit tests, and dependency resolution onto cheap Linux runners and reserve macOS and Windows for signing, packaging, and platform UI tests. The platform-specific surface is far smaller than the matrix that grew around it, so pruning cuts non-Linux spend with no loss of coverage.

Evaluate managed runners before you staff a platform team, not after

The managed-runner break-even arrives before a scaleup has the headcount to run a fleet in-house, capturing most of the per-minute spend with zero fleet ops. The moment you feel the CI bill is the moment to evaluate the runner layer, because waiting until a platform team exists gets the sequence backwards and pays for the fix under pressure.

Outlook

Through 2026 and 2027 the scaleup CI inflection will keep arriving on schedule, because the forces behind it, growing codebases, rising merge frequency, broadening matrices, are intrinsic to growth itself. The variable is not whether a scaleup hits the curve but whether it sees the curve coming. The teams that treat the fifty-engineer line as a known milestone and prepare the runner layer and caching discipline in advance will bend the curve cheaply; the teams that wait for the bill to force the issue will pay for the same fix under duress.

The role of the first platform team will keep shifting from firefighting toward prevention as the playbook becomes better understood. Today most platform teams form reactively and spend their first quarters retrofitting hygiene that should have been built in. As the scaleup CI pattern becomes common knowledge, more teams will invest in caching, right-sizing, and managed runners before the platform team exists, so that when it does form, it inherits a tractable system rather than a fire.

The economic direction is settled. For a scaleup, the relevant comparison was never instance price versus hosted price; it is total cost of ownership including the platform-engineering time a self-hosted fleet quietly consumes. Because that time is the same scarce resource a scaling company most needs to point at product, the managed runner layer that removes idle, ops, and mechanical waste is converging into the default. The scaleups that internalize this will spend the next two years treating CI as a controlled, forecastable line item rather than a compounding surprise.

Methodology

This report synthesizes publicly available industry data (developer surveys and the DORA State of DevOps research) with Latchkey's own analysis of scaleup CI economics. The 4.2x CI-minutes growth past roughly fifty engineers, the per-engineer minute curve, the build-time curve, and the CI-spend split are Latchkey modeled estimates derived from typical scaleup pipeline shapes and published runner pricing, not a primary survey, and are labeled as such. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• Stack Overflow Developer Survey
• DORA State of DevOps Report
• GitHub Actions - billing & pricing
• GitHub - Octoverse

More Latchkey reports