Procurement Archetypes: Build vs Buy vs Rent

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

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

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 each can usually be satisfied more than one way. The fourth, how long and how certainly the workload will run, 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 (a contested 2–3-year obsolescence bear case at the frontier) can be shorter than the debt tenor used to buy it, and 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. Neoclouds, colos and self-builds are gated by different things: provider capacity, fit-out, grid service, behind-the-meter generation, utility upgrades. Read time-to-power off your own tariff, studies and equipment schedule, not a national year range. When it binds, the decision collapses toward whoever already holds energized capacity, almost regardless of unit cost. That is why neoclouds exist as a category, and why colocation pricing hit record highs in 2025, with vacancy near zero in the tightest hubs and materially looser elsewhere. The scarce good is not space but power that is already on, in the market you need.

Capital intensity 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. The tenant still buys the servers and network, roughly 69% of the total. Only a neocloud converts the whole stack into a per-GPU-hour rate, so a tenant-owned AI fleet is not capex-light just because its building is leased. For a startup, an enterprise dabbling, or a sovereign program racing a political clock, the capex wall alone rules out self-build. Control 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 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, because 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, power chain, cooling plant and fabric to your workload's exact cascade, and at scale and high utilization you avoid the rental margin, but you carry the whole ownership stack: 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 shrinks that cushion while the scheduled payments stay 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 denser AI racks is fast and cheap relative to greenfield, but the existing slab, plenum, electrical headroom and heat-rejection path cap how far you can push density. Enabled Energy estimated $5–6M/MW in July 2025 for an existing-hall upgrade supporting 20–40 kW racks. A liquid-cooled rack-scale conversion needs a separate facility scope and budget. A hall scoped for 40 kW air-cooled racks cannot absorb the rack-scale ramp a retrofit has to survive inside its lease term: NVIDIA specifies up to 142 kW for GB300, and its DSX reference design uses 330 kW cabinet TDP as the facility basis for Vera Rubin NVL72 (VR200) power and cooling (checked October 2026). OEM datasheets rate operating profiles at 188 kW Max Q and 228 kW Max P. Kyber's ~600 kW figure is a roadmap planning point: NVIDIA targets Rubin Ultra for H2 2027, while SemiAnalysis reported a Kyber delay to 2028 in July 2026, which NVIDIA disputed (see Chapter 1.1's cooling cliff). 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, because the long-lead power and building work is already done and provider availability and fit-out are the remaining gates. The cost is a per-kW-month lease and a shared shell whose redundancy tier and power limits you accept rather than design. CBRE's inventory-weighted global pricing benchmark was $217.30/kW-month in Q1 2025, and its Q1 2026 report quotes $190–235/kW-month in Northern Virginia for 250–500 kW requirements; price the actual AI-ready hall and density as a separate deal. 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, with the provider controlling the underlying fabric and reliability. Neocloud and hyperscaler prices differ by GPU generation, location, commitment and service scope, so compare contemporaneous, workload-specific quotes for the same paid capacity in Chapter 1.8. That flexibility is what makes rental viable for spiky, short, experimental or burst-overflow demand. The category carries two 2026-specific cautions. Pricing is volatile: SemiAnalysis's one-year H100 contract index rose about 40% between October 2025 and March 2026 as capacity tightened. Its April 2026 report described on-demand capacity as largely sold out, with reserved capacity booked months ahead, so the "rent it instantly" promise depends 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 hardest. These archetypes are complements layered against the shape of your demand curve, which the hybrid strategies below put to work. First reject options that miss the service or delivery date. Then add tenant IT, power, network, support, migration, egress and paid reserve to each quote, and 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. It maps onto Chapter 1.1's training-shaped versus inference-shaped fork: compare ownership for demand you have proven durable and rental for the contractual flexibility it needs, whether the workload is training or inference.

Colo-anchor-plus-cloud-overflow. Anchor a committed, predictable load in a wholesale colo on a multi-year lease (facility capex moves to the landlord, but you still fund the IT, and delivery and control need separate checking), and absorb peaks, such as the bursty 30%-to-90% swings an online-inference business sees in minutes, with 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. That is the point: rental's high unit cost is acceptable precisely when it applies 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 where owning beats renting depends on paid capacity, economic earning life, net resale proceeds and the matched cash-flow schedule, and Chapter 1.8 treats it quantitatively.

Every procurement choice above assumes power exists to be procured. In 2026 that assumption is the project's most dangerous one. Time-to-power depends less on how fast you can build than on 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 stays a non-revenue project until that milestone arrives. The power gate can invert the build-versus-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 and 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. 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). On 27 July 2026, PJM's Board directed filings for a Large Load Registry and Interim Resource Adequacy Service. The proposal would curtail new large loads before Pre-Emergency Load Management during capacity shortages from 1 June 2027 if they neither bring generation nor otherwise secure supply. 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). Wood Mackenzie estimates utilities will commit only about 28% of the 1,066 GW of requested US data-center load (Bloomberg, 12 August 2026), so 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 but the only path to revenue inside your depreciation window.

Behind-the-meter (BTM) generation supplies the campus on its side of the utility meter through on-site or dedicated private-wire plant. Nuclear and SMR PPAs secure an energy purchase; they bypass the load's grid-service gate only when the physical supply arrangement does so (Chapter 3.4 and Chapter 3.5). BTM is the escape hatch and has become a primary procurement gate in its own right. On-site gas can beat the grid-service date when equipment delivery, fuel supply, permits and commissioning finish sooner, which is why announced BTM gas reached on the order of ~90 GW cumulatively by mid-2026. That is an announcement-stage figure, not a built one: only ~2 GW was operating (mostly xAI's Colossus turbines) and roughly 1% was under construction (Cleanview, mid-2026). A major planned example is Amazon's Pecos County campus at GW Ranch, where Pacifico Energy obtained an air permit for up to 7.65 GW of gas-fired generation in January 2026; that figure is permitted generation capacity, not energized IT load (Pacifico Energy, 26 January 2026; DCD, 10 August 2026). Aeroderivative schedules are project-specific: GE Vernova's July 2026 announcement of Hawaiian Electric's LM6000VELOX order targets the first two units in commercial operation in 2029. Schedule BTM against the reserved equipment-delivery slot and the complete site commissioning plan. 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 it 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 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 behind-the-meter generation assets, which carry their own depreciation and cannot be unwound cheaply. A wrong demand forecast compounds here: 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. A committed reservation is different. 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. Also reversible: 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 as insurance against the demand curve you assumed being wrong. → refresh and re-homing 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. Where the demand trace supports both, compare a colo anchor with reserved rental overflow.
• 2. What is the time-to-power need? Revenue needed in weeks: test available neocloud allocations. In months: test colo inventory that fits your spec. 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? Strict placement, collective, tail-latency, density or cooling constraints: own, or choose a provider that contractually proves the target profile. More portable profiles: any path whose measured fabric, capacity and SLO results hold up.
• 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, leased or 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 the provider's margin over ownable cost year after year on compute you should own. The fix is the own-versus-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 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.