Buying, Building and Configuring

Teams facing a slow toolchain reach for a purchase. The evidence usually says configuration first.

What you already own

Incrementality in your build tool, frequently misconfigured rather than absent.

Caching, often available and unenabled or badly keyed.

Parallelism settings, usually at conservative defaults.

Test selection, available in several build systems natively.

CI concurrency and cancellation, a settings change.

Timing telemetry, emitted by most build tools and collected by nobody.

Work through these before evaluating anything. They cost days and frequently halve the number that prompted the conversation.

What a product adds

Remote cache infrastructure, operated. Running your own is possible and is a service with availability requirements.

Build analytics, with the storage, query and visualisation already built.

Test selection and flake detection, as a maintained implementation rather than a homegrown script.

Distributed execution, which is genuinely hard to build.

Support, for a system that everyone depends on daily.

The infrastructure and the analytics are the real purchase. The insight is not proprietary; the operating burden is.

When building is defensible

A small estate, where a script and a spreadsheet answer the questions.

An unusual requirement no product meets.

Data that cannot leave your environment.

Existing platform capacity with a named owner for the next several years.

Where the build tool already provides most of it and you need only a cache backend, which is a modest service.

When it is not

When nobody will own it. An unmaintained analytics pipeline produces confidently wrong numbers, which is worse than none.

When the operating burden is the point. A remote cache is a production service: availability, capacity, correctness. Underestimating that is the usual mistake.

When flake detection is the requirement, which needs per-test history storage and query — more work than it looks.

When the driver is avoiding a licence cost smaller than the engineering time.

Evaluating a product

Trial on your own codebase, not on a sample. The awkward parts of your build determine the result.

Measure the cache hit rate you actually achieve, not the one demonstrated. If your build is not reproducible, the hit rate will be poor whatever the product does.

Ask what it does with a build it cannot model — undeclared inputs, non-hermetic tasks.

Ask about the identity model: can it aggregate at ingestion, or does it store per-developer records with a reporting filter on top. This determines whether your telemetry boundary is architecture or convention.

Test the export. Build history is expensive to accumulate and you should be able to leave with it.

Log your own hours during the trial, which is the cost that never appears in the business case.

The order

Configure what you own. Measure what remains. Buy for the remainder.

A requirement written from evidence is narrower and cheaper than one written from a capability list, and it survives the conversation with finance.

The remote cache as a service

The component most often underestimated when building rather than buying.

It is a production dependency. When it is down, every build is slow and every developer notices within minutes.

Availability requirements are high and higher than most internal services.

Storage grows continuously and needs eviction, which is a policy decision with correctness implications.

Correctness matters more than uptime: a wrong entry served is worse than an outage.

Access control is not optional, since write access is the ability to poison everyone's build.

Estimate this properly before deciding to build it, because it is the part that is cheap to start and expensive to operate.

Testing the export

Build history is expensive to accumulate and you should be able to leave with it.

Export during the trial, not at renewal.

Check the format is usable in something else.

Check what is included: runs, stages, tests, cache events, or only summaries.

Ask what happens to the data after termination and how long it remains available.

A product whose export omits the per-test history is one you cannot leave without losing the flake detection you built on it.