Neocloud buyers optimize for speed and certainty on mid-size deliverable loads. Hyperscale procurement optimizes campus scale, expansion rights, and process discipline. The site selection checklist looks similar on paper. The weights are different in practice.
For developer sites teams, that difference decides which parcels stay on the shortlist. A site that fits a hyperscale campus process can be the wrong product for a neocloud that needs earlier energization and cleaner delivery risk.
Quick definitions
Hyperscale buyers are large cloud and internet operators that procure large campuses, often through mature real estate and procurement machines, with heavy emphasis on expansion rights, standardization, and long-horizon delivery.
Neocloud buyers are specialized AI cloud or GPU-cloud operators that sell accelerated compute capacity. Their site needs are still power-first, but the commercial clock is usually tighter, the initial load block is often smaller than a full hyperscale campus, and delivery certainty can outweigh optional expansion land.
Neither label replaces diligence. Both still fail without deliverable power, workable land, fiber, and a realistic entitlement path.
What stays the same
Both buyer types still require:
A named load profile and ramp
Deliverable power, not map-level available capacity
Fiber access with meaningful route diversity
Usable land after constraints
A zoning and public-process path that can survive scrutiny
Control terms that match remaining diligence
If a team skips those gates because the buyer brand is strong, the site is not selected. It is hoped into the pipeline.
What changes in the weights
| Criterion | Neocloud emphasis | Hyperscale emphasis |
|---|---|---|
| Initial load block | Mid-size phases that can energize sooner | Large campus blocks and multi-phase master plans |
| Timeline | Speed to first useful MW often decisive | Process quality and long-horizon delivery can dominate |
| Expansion land | Useful, but secondary to near-term delivery | Often core to the deal thesis |
| Power evidence | High bar for dated deliverability | High bar plus optionality for later phases |
| Fiber and latency | Often critical for product performance | Critical, with campus-scale network design |
| Entitlement risk | Low tolerance when schedule is tight | Managed through process, counsel, and phasing |
| Lease and credit posture | More scrutiny on newer credits and security packages | Mature negotiation playbooks and standardized asks |
| Behind-the-meter options | Attractive when they protect timeline | Attractive when they protect campus scale and control |
The practical takeaway: acreage is rarely the first differentiator. Delivery shape is.
How screening should change
For neocloud-led pursuits
Fix the first energization block before hunting for the largest tract.
Rank sites by deliverable MW in the required window, then by fiber and entitlement friction.
Keep expansion land as upside, not as the reason to accept a soft power path.
Kill early when the utility date is marketing-grade or the public process is open-ended.
Bundle validation and closing services around the same evidence ledger so the team does not rediscover gaps after LOI.
For hyperscale-led pursuits
Test campus geometry, phasing, and expansion rights as first-class constraints.
Model power as a multi-phase programme, not a single day-one number.
Expect heavier process: procurement gates, technical standards, and documentation depth.
Still refuse sites that only offer available capacity language for later phases.
Separate "fits the campus story" from "phase one is actually deliverable."
Common failure modes
Neocloud failure mode: choosing a beautiful campus site that cannot energize the first block on time. The product needs capacity in market, not a land bank narrative.
Hyperscale failure mode: locking a site on phase-one optimism while expansion power and entitlement remain speculative. Campus value collapses if later phases are not real.
Shared failure mode: treating broker availability claims as deliverable capacity, or treating fiber as a late check after power is "solved."
What developers should put in the IC memo
For either buyer type, the memo should answer:
What load is real for phase one, and what is optional later?
What evidence supports deliverable capacity for that phase?
What fiber and entitlement risks can still break timing?
What control structure preserves exit rights while diligence finishes?
What bundled work is required between validation and close?
If the memo cannot answer those in plain language, the site is not ready for pursuit intensity.
Decision rule
Select for the buyer's delivery problem, not for a generic data center score.
If the buyer needs speed and certainty on a mid-size block, prefer sites with dated deliverable power and lower process friction, even if the campus story is smaller. If the buyer needs hyperscale campus optionality, prefer sites that can support phased delivery and expansion without pretending later MW are already secured.
Then validate the site fully and bundle the services that turn a shortlist into an acquisition-ready package.