Procurement Archetypes: Build vs Buy vs Rent

Chapter 1.1 asked the first orthogonal question — what runs here. The second, independent question is how you acquire the capacity to run it. The two are distinct questions, but their answers constrain each other: a frontier pre-training run can be served from a self-build, a colo, or a neocloud, and an online-inference business can be any of the four. The workload question is reopened when the model, traffic, service objective or supported equipment changes. The procurement question is answered repeatedly, is mostly about finance and time, and is where most operators in 2026 are actually getting hurt — not because they pick the wrong cooling, but because they commit capital to a demand forecast they could not honestly defend, or because they rent at a premium for years a load they should have owned.

The fork is build vs buy vs rent, across four paths: greenfield self-build, brownfield retrofit, colocation (wholesale or retail), and neocloud / GPU rental. We trace each against the four levers that decide it — time-to-power, capital intensity, control, and the workload-duration / demand-certainty axis that quietly dominates the other three. We then treat the two structural realities that reshape the whole decision in 2026: the power gate (grid interconnection vs behind-the-meter generation), and demand uncertainty, which converts the build-vs-lease choice from a cost comparison into an options problem. The cost stack and option framing that score these paths live in Chapter 1.8; the deal mechanics and accounting in Chapter 2.5; the strategy that sits above both is the subject here.

Practitioners list four decision drivers — time-to-power, capital intensity, control, workload duration — as if they were peers. They are not. The first three are real constraints, but they are usually satisfiable in more than one way. The fourth — how long and how certainly the workload will run — is the lever that breaks ties and, more often than not, makes the decision outright. The reason is depreciation. An AI cluster is the rare capital asset whose useful-life assumption (a contested 2–3-year obsolescence bear case at the frontier) can be shorter than the debt tenor used to buy it; a 5–6 year book life is an accounting schedule, not a financing term. Commit to a self-build for a workload that evaporates in eighteen months and you own a stranded asset against a loan that outlives the revenue. With cancellable rental you stop paying at the agreed break date; a take-or-pay allocation keeps billing after the workload ends.

Time-to-power is the lever that has moved most since 2020, because the binding constraint is no longer chips or capital but megawatts. A neocloud, colo and self-build are gated by different things — provider capacity, fit-out, grid service, behind-the-meter generation, utility upgrades — so read time-to-power off your own tariff, studies and equipment schedule, not a national year range. When time-to-power is the binding constraint, the procurement decision collapses toward whoever already holds energized capacity, almost regardless of unit cost. Neoclouds exist as a category for that reason, and colocation pricing hit record highs in 2025 for the same one, with vacancy near zero in the tightest hubs and materially looser across other regions: the scarce good is not space, it is power that is already on, in the market you need it in.

Capital intensity is the lever that decides who can play at all. A 1 GW self-build runs on the order of tens of billions up front, but the capital boundary moves by structure, not by a single fraction. A colo lease converts the facility share — about 30% of program capex in the Epoch reference model — into a per-kW-month operating expense while the tenant still buys the servers and network that are roughly 69% of it; only a neocloud converts the whole stack into a per-GPU-hour rate. A tenant-owned AI fleet is not capex-light because its building is leased. For a startup, an enterprise dabbling, or a sovereign program racing a political clock, the capex wall alone forecloses self-build. Control is the lever that pulls the other way: only a self-build (and to a bounded degree a retrofit) gives you authority over density, power architecture, cooling modality, fabric topology, and reliability posture — the very levers Chapter 1.1's cascade showed are load-bearing for a training-shaped facility. Rent, and you inherit the provider's fabric, placement controls, failure headroom, and uptime. Before accepting that, validate the provider's fabric against your measured traffic and your step-time or tail-latency SLO — workload type alone does not set a blocking ratio.

Greenfield self-build is the maximal-control, slowest, most capital-intensive path; its long-run unit cost beats rental only when matched prices and cash flows support it. You design the slab, the power chain, the cooling plant, and the fabric to your workload's exact cascade, and at scale and high utilization you avoid the rental margin but carry the ownership stack yourself: accelerator, fabric, network, and storage capex; financing; energy and PUE; spares and operations; useful life; and residual value. A frontier self-build must price the selected rack-scale platform, and Chapter 1.8 turns those inputs into the ownership case. The price is a multi-year, queue-gated schedule to a live cluster, the deepest capital commitment, and an interconnection slot that is itself the scarcest asset in the project. Self-build requires demand durable enough to amortize all of that and prices that make the matched cash flows in Chapter 1.8 favor ownership; high utilization alone cannot establish a rental-margin saving. Debt adds a separate cash test: the contribution from sold GPU-hours, after variable cost, must cover fixed operating cash and scheduled debt service. Lower utilization or a lower realized rental price reduces that cash cushion while the scheduled payments remain due. Compute that threshold from your own purchase price, contract rate, variable cost, and financing in Chapter 2.5; it does not decide buy versus rent.

Brownfield retrofit trades capital and schedule for a hard physics ceiling. Converting an existing air-cooled hall to host dense AI racks is fast and cheap relative to greenfield — roughly ~$2M/MW for the cooling upgrade alone and ~$5–6M/MW for a full AI retrofit, rising toward greenfield parity at full AI density — but the existing slab, plenum, electrical headroom, and available heat-rejection path cap how far you can push density. A hall scoped for 40 kW air-cooled racks cannot absorb the NVL72-class ramp a retrofit has to survive inside its lease term: NVIDIA's full-rack requirement of up to 142 kW for GB300, its 330 kW cabinet facility design basis for VR200, and its ~600 kW H2 2027 roadmap planning point for Kyber (Chapter 1.1's cooling cliff). An estimated two-thirds of pre-2015 data centers are unsuitable for frontier AI density without effectively rebuilding them. Retrofit is the right call for bridge capacity and for modest-density inference that lives comfortably under the air-cooling cliff — and the wrong call the moment your roadmap crosses into training or next-generation dense inference. → Chapter 5.10.

Colocation — wholesale (you lease a powered hall and own the IT) or retail (you rent cabinets and power by the rack) — buys time-to-power by renting someone else's energized shell. A live 50k+ GPU cluster can stand up in a wholesale hall far faster than any build: the long-lead power and building work is already done, leaving provider availability and fit-out as the gates. The cost is paid in a per-kW-month lease (global wholesale averaged roughly $217/kW-month in 2025, a record, ranging from ~$120 in Atlanta to ~$450 in Singapore) and in a shared shell whose redundancy tier and power envelope you accept rather than design. Colo is the natural home for medium-term, scaling, demand-uncertain workloads — and the anchor of most hybrid strategies.

Neocloud / GPU rental compresses time-to-first-job to however fast a provider can hand you capacity, and converts capex entirely into opex, at the contracted per-GPU-hour rate and with provider control over the underlying fabric and reliability; compare its full paid-service cash flows in Chapter 1.8. Neocloud rates run 40–85% below the hyperscalers (a current-generation 8-GPU node averaging ~$34/hr on a neocloud vs ~$98/hr on a hyperscaler in 2026; the H100-class neocloud median runs ~$2.3–3.5/GPU-hr, i.e. ~$18–28 per node), which is what makes rental viable for spiky, short, experimental, or burst-overflow demand. But the category carries two 2026-specific cautions: pricing is volatile (the one-year H100 contract index rose ~40% between October 2025 and March 2026 as capacity tightened), and on-demand capacity has been effectively sold out across most GPU types with reserved capacity booked months ahead — so the "rent it instantly" promise is conditional on a market that periodically has nothing to rent.

Read down the unit-cost column and the temptation is to self-build everything. The time-to-power and demand-profile columns push back: an apparently cheapest-per-hour build can also be the slowest and the one that punishes a wrong demand forecast most severely. These archetypes are complements layered against the shape of your demand curve, which is what the hybrid strategies below operationalize. First reject options that miss the service or delivery date. Then add tenant IT, power, network, support, migration, egress and paid reserve to the quote; compare the same demand horizon in Chapter 1.8.

In practice almost no serious operator picks one cell. The demand curve has a stable base and a volatile tail, and the right strategy matches each layer to the archetype whose cost structure fits it. Three patterns recur:

Build-core-rent-edge. Own the durable base load where you are most certain of demand and most need control (a self-built training core), and rent the geographically distributed inference tail from colos and neoclouds near users, where proximity matters more than unit cost and demand is harder to forecast site by site. This is the canonical hyperscaler and large-neocloud posture, and it maps cleanly onto Chapter 1.1's training-shaped vs inference-shaped fork: compare ownership for durable qualified demand and rental for the contractual flexibility it needs, whether training or inference.

Colo-anchor-plus-cloud-overflow. Anchor a committed, predictable load in a wholesale colo on a multi-year lease (facility capex transferred to the landlord, with tenant IT still funded and delivery/control separately qualified), and absorb peaks — the bursty 30%-to-90% swings an online-inference business sees in minutes — by using a prequalified neocloud allocation whose reserved capacity and startup time fit those peaks. You pay for the volatile fraction plus any minimum commitment and standby capacity needed to make the overflow dependable, which is the point: rental's high unit cost is acceptable precisely when it is applied to the part of demand you could not have committed to in advance.

Burst-to-neocloud (bridge and experiment). Run steady state on owned or colo capacity, and use neocloud rental as a bridge while a self-build energizes, as elastic capacity for a one-off training run or evaluation sweep, or as the proving ground for a workload whose durability you do not yet trust. When a rented workload proves durable and large, re-test ownership against the eligible rental quote, migration cost and delivery schedule — the crossover point where owning beats renting is a function of paid capacity, economic earning life, net resale proceeds and the matched cash-flow schedule, and is treated quantitatively in Chapter 1.8.

Every procurement choice above assumes power exists to be procured. In 2026 that assumption is the project's most dangerous one. Time-to-power is set less by how fast you can build than by how fast you can energize, and energization runs through one of two gates — grid interconnection or behind-the-meter generation — whose lead times can dominate every other line in the schedule. A self-build that finishes before its contracted host-utility energization milestone remains a non-revenue project until that milestone closes. The power gate can invert the build-vs-rent ranking outright.

Grid interconnection is the default and, increasingly, the bottleneck. Large-load service follows the governing utility or RTO tariff and project-specific studies, upgrades, agreements and milestones. The national queue measured in thousands of gigawatts is generation/storage supply-side context, not a data-center load queue. The regulatory ground is moving fast: FERC's December 2025 PJM colocation order forced standardized service terms for loads co-located with generation, and DOE's October 2025 directive matured into FERC's 2026-06-18 show-cause orders directing all six RTOs/ISOs to justify or reform their large-load tariffs (the RTOs won ~90-day abeyances in mid-August). PJM's Board added a Large Load Registry and, from 2027-06-01, first-to-curtail status for new large loads that bring no generation. Texas went further: the governor paused ERCOT's Batch Zero large-load process on 2026-08-03 pending a project-by-project audit, since partly reopened through PUCT exceptions and a conditional-classification route (ERCOT, 2026-09-03), and analyst conversion estimates say well under a third of requested US data-center load will ever be committed — a queue position is an option, not a plan (Chapter 3.2 for the numbers and mechanics). The consequence for procurement is direct: if your candidate site's queue position is bad, colo or neocloud is not a fallback, it is the only path to revenue inside your depreciation window.

Behind-the-meter (BTM) generation — gas turbines, on-site generation, increasingly nuclear and SMR PPAs — is the escape hatch, and it has become a primary procurement gate in its own right. On-site gas can bring power in 18–36 months, faster than many grid queues, which is why announced BTM gas reached on the order of ~90 GW cumulatively by mid-2026 — an announcement-stage figure, not a built one: only ~2 GW was actually operating (mostly xAI's Colossus turbines) and roughly 1% was under construction (Cleanview, mid-2026), with the largest confirmed single campus being Amazon's off-grid gas site in Pecos County, TX (Chapter 3.5). Aeroderivative turbines, the fast option, now carry 18–36 month lead times themselves as orders surge. Choosing BTM buys speed-to-power and revenue — getting 200 MW online six months early is worth ~$1.2B at ~$12–13B/GW/yr of AI revenue — but trades grid economics, exposes you to fuel and emissions risk, and locks in generation assets with their own depreciation profile. → Chapter 3.2 (speed-to-power) and Chapter 3.1 (the reordered siting hierarchy).

Chapter 1.1 sorted the physical decisions by reversibility. The procurement stack has its own register, and it is where the demand-uncertainty hedge actually gets spent.

Irreversible (decide once, hedge now): the self-build slab and its interconnection slot; the take-or-pay power contract (a multi-year firm commitment to buy energy whether or not you use it); the long BTS lease; and the behind-the-meter generation assets, which carry their own depreciation and cannot be unwound cheaply. These are the decisions where a wrong demand forecast compounds — you pay for capacity you do not use against a contract you cannot exit.

Reversible (defer, keep cheap): on-demand and spot neocloud volume, which you switch or stop as you consume it — but not a committed reservation: CoreWeave's committed contracts, over 98% of its 2025 revenue, are take-or-pay with a weighted-average duration of about five years (2025 Form 10-K), so reversibility is set by the term and the break rights, never by the provider category; the colo expansion option (exercise it only when demand materializes); the burst-overflow relationship; and the IT fit-out generation within a powered shell. The strategic move, identical in spirit to Chapter 1.1's, is to convert irreversible commitments into reversible ones wherever the option premium is cheap: a powered shell instead of a BTS, a colo lease with expansion rights instead of a self-build, a burst-to-neocloud bridge instead of energizing owned capacity ahead of demand. You pay the rental and lease premiums precisely as insurance against the demand curve you assumed being wrong. → refresh and re-home execution in Chapter 14.9.

The archetype choice is a short ordered set of questions, each of which can foreclose later options:

• 1. How certain is the demand? Durable and contracted → test a long commitment. Spiky or short → value cancellation and staged commitments. Compare a colo anchor with reserved rental overflow where the demand trace supports both.
• 2. What is the time-to-power need? Revenue needed in weeks → test available neocloud allocations. In months → test qualified colo inventory. In years → compare a self-build against the need-by schedule and demand horizon. If the need is fast but the demand is durable, bridge with rental while a build energizes.
• 3. What does the workload demand in control? Workloads with strict placement, collective, tail-latency, density, or cooling constraints → own or select a provider that contractually proves the target profile. More portable profiles → any path whose measured fabric, capacity, and SLO evidence closes.
• 4. What is the power gate? A bad interconnection queue can convert "self-build" into "colo or neocloud by necessity," or push you toward a behind-the-meter path with its own lead time and economics. Resolve this before committing to any owned path.
• 5. Which commitments are you about to make irreversible? Tag every take-or-pay, lease term, slab, and generation asset, and ask whether a powered shell, an expansion option, or a rental bridge could keep it reversible at an acceptable premium.

The output of this sequence is the procurement layer of the design-basis document from Chapter 1.1: which load is owned, which is leased, which is rented, what the power gate is, and which commitments are hedged versus fixed — signed before any long-lead equipment or power contract is ordered.

Each recurring procurement mistake comes from optimizing one lever in isolation and ignoring the demand-certainty axis that should have governed it:

• Building against an assumed demand curve. Self-building (or signing a long take-or-pay) for a workload whose durability was assumed, not contracted. When the curve disappoints, you own a stranded asset that runs cash-negative below its cash-breakeven utilization against debt that outlives the revenue. The fix is to rent or colo the uncertain fraction until it proves durable.
• Renting a certainty. Keeping a large, durable, high-utilization base load on neocloud for years out of inertia, paying a 2–4x markup over ownable cost repeatedly on compute you should own. The fix is the own-vs-rent crossover re-test in Chapter 1.8.
• Ignoring the power gate. Selecting a self-build site on land and construction economics without a contracted host-utility path, study and upgrade scope, milestones and bridge option can miss the depreciation window entirely. Treat the governing tariff and energization path as first-order procurement inputs.
• Retrofitting past the air-cooling cliff. The procurement-flavored version of Chapter 1.1's cooling-cliff anti-pattern: choosing a cheap, fast brownfield path for a roadmap that will cross into training-class density, then stranding capacity at a cost that would have funded a purpose-built liquid hall. → Chapter 5.10.