An Old Observation, a New Application

The picks-and-shovels observation is not new. It has been applied to every major technology buildout since the railroad era. The original observation is approximately: during the California Gold Rush, the prospectors who got rich finding gold were outnumbered by those who got rich selling equipment to the prospectors. The "picks and shovels" — the tools required to pursue the opportunity — often outperformed the direct pursuit of the opportunity itself.

Why does this pattern repeat? And does it apply to the AI infrastructure cycle? The BTT framework provides a rigorous answer to both questions.

The Structural Advantage of Infrastructure

Infrastructure positions in major capital cycles have a structural advantage over application layer positions that comes from the fundamental difference between forced-spend and discretionary spend.

Application layer spend is discretionary. An enterprise deciding which AI software to purchase can evaluate options, negotiate pricing, switch vendors, delay the decision, or build in-house. The application vendor must continuously compete for purchase decisions that are not guaranteed.

Infrastructure spend is non-discretionary. A data center that needs power cannot evaluate whether to buy a transformer — it must buy one. An AI training cluster that requires high-bandwidth memory cannot negotiate with the laws of GPU architecture — the memory must be procured. The forced-spend characteristic of infrastructure makes it structurally advantaged compared to discretionary application layer spend.

The Historic Pattern

The picks-and-shovels dynamic has appeared consistently in every major technology buildout cycle:

Telecommunications buildout (1990s): Fiber optic cable, network switching equipment, and telecommunications infrastructure manufacturers outperformed the internet application companies that eventually ran on the infrastructure. The infrastructure companies had multi-year procurement contracts before the applications were profitable. Many application companies failed; the infrastructure remained in use.

Cloud computing buildout (2010s): The companies supplying servers, networking equipment, and cooling systems to hyperscalers generated sustained, contracted revenue from the cloud buildout before the SaaS and application businesses built on top of that infrastructure were mature. Infrastructure suppliers had procurement visibility. Application companies had venture financing.

AI infrastructure (2020s): The current cycle. GPU manufacturers, power equipment suppliers, memory manufacturers, and thermal management companies are receiving multi-year procurement commitments from hyperscalers — the same hyperscalers whose AI application businesses are still in the early stages of monetization. The infrastructure is being purchased now. The application revenue is coming later.

Why Application Layer Underperforms in Buildout Phases

The application layer is not a bad investment in the long run — in mature technology cycles, the application companies often generate the largest total market caps. But in the buildout phase of a cycle, they underperform infrastructure for several reasons:

Lack of procurement visibility: Application companies compete for customers who can choose among alternatives. Infrastructure companies receive committed procurement contracts years in advance.

Competitive intensity: Application markets attract more competitors than infrastructure markets, because the barriers to entry are lower. Infrastructure manufacturing requires capital, regulatory approvals, specialized expertise, and established customer relationships that are difficult to replicate.

Valuation timing mismatch: Markets tend to price application layer on discounted cash flows from future revenue that has not yet arrived. Infrastructure is priced on current backlog and current contracts. During the buildout phase, the application layer is more expensive on a fundamental basis because it is being priced on speculative future cash flows.

The BTT Framework as a Picks-and-Shovels Filter

The BTT framework is, in essence, a systematic application of the picks-and-shovels heuristic. By focusing specifically on supply chain constraints — the physical, structural bottlenecks that any version of the AI buildout must resolve — BTT automatically selects for infrastructure positions over application positions.

Every position GZC holds in the Technology pool was identified through this framework. Each represents a supply chain bottleneck: non-discretionary demand, concentrated supply, multi-year procurement visibility. None were identified because we believe in a specific AI application company's business model.

This is not because AI application businesses are bad investments. It is because infrastructure positions, at this stage of the buildout cycle, have better return characteristics for the risk we are taking. The supply chain contracts are real. The demand is non-discretionary. The competitive moats are defined by manufacturing expertise and procurement relationships, not by software features that can be copied in a weekend.

The Limitation of the Heuristic

The picks-and-shovels heuristic is not universally applicable. It works best in the buildout phase of a capital cycle — when infrastructure spend is front-loaded and application spend is deferred. As cycles mature, application businesses often generate better returns than the commodity infrastructure underlying them.

The AI infrastructure buildout is, by our assessment, in its early-to-mid phases. The infrastructure has not been built. The power grid cannot serve the load that has been committed to. The memory manufacturing capacity cannot meet the demand that GPU roadmaps project. The application layer — AI software businesses — are promising but dependent on infrastructure that does not yet exist at the required scale.

For GZC's Technology pool, this means the infrastructure-over-application positioning is appropriate now, and we expect to maintain it for the foreseeable future. When the evidence suggests the cycle is maturing — when infrastructure constraints are normalizing and application revenues are demonstrating scale — we will reassess.