JetBrains documents shared indexes for IntelliJ IDEA - indexes generated once on one machine and reused on another so each developer does not rebuild them, distributed through file storage or any S3-compatible storage. A platform team at a 900-engineer company proposes publishing them for the main repository. What is gained, what does the platform now own, and when does the bill arrive?

What is gained

Project indexing is work that is identical on every machine and currently done 900 times. Centralising it converts a per-engineer CPU cost into one build plus a download. On a large repository the first-open index is minutes of full-core CPU, and it recurs after any change that invalidates a large share of the index - a dependency bump, a branch switch across a big refactor, an IDE upgrade.

The useful detail is that JetBrains ships a command that reports indexing time with and without the shared indexes, so the saving is measurable on the actual repository before anything is rolled out. A platform team that cannot produce that number before the project starts is guessing.

What the platform now owns

• A build-and-publish pipeline. Indexes have to be generated per repository state, uploaded, and retained with a lifecycle policy. Artefacts are large, so this is a storage and bandwidth line item, not a script.
• A cadence decision. Index reuse is matched against file content, so a developer on a branch that has diverged gets reuse only for the files that have not changed, and the benefit decays with divergence. The publishing cadence is therefore set by repository churn - typically per merge to the main branch, or nightly for an estate that moves more slowly.
• An IDE version policy. An index is only usable by an IDE that can read it. Publishing indexes couples the platform to which IDE build 900 engineers run, which means the platform is now in the business of telling people when to upgrade their editor.
• A documented degradation path. The IDE processes local and shared indexes together, which can raise CPU on the developer's own machine, and JetBrains documents a "wait for shared indexes" option for exactly that. A platform shipping this needs a position on which setting is the default.

When the bill arrives

Not at rollout, which is where it looks cheapest. It arrives at the first IDE upgrade cycle after people have come to depend on it, when the published set is stale for the new build and the fast path quietly disappears for everyone who upgraded. It arrives again the first time the publishing job breaks and nobody notices, because nothing fails - indexing simply becomes local again and the complaint arrives as "the IDE feels slow lately", weeks later. Instrument the hit rate per engineer or the capability has no signal at all.

When this is the wrong answer

Below a few hundred engineers, or where full indexing is already under a minute, this does not pay. The pipeline, the storage, the version policy and the support load are fixed costs, and they are justified only by multiplying a real per-engineer saving by a large number of engineers.

It is also the wrong first move if the measured number says the dominant inner-loop cost is elsewhere. If engineers lose 12 minutes a day to a test suite and 2 minutes to indexing, the index project is the comfortable problem rather than the expensive one.

Common weak answers

• "Give everyone faster laptops." That buys a fraction of one index build and nothing else, and it scales linearly with headcount rather than being paid once.
• "Mandate the shared index setting through policy." If the hit rate is low because the published set is stale, mandating it makes the IDE do both kinds of work.