The Need for Speed

In March, news headlines suggested that Microsoft had walked away from data-center projects amounting to roughly 2 gigawatts of capacity across the U.S. and Europe, an eyebrow-raising figure in an era when “AI is eating all the power.” Analysts framed the move as a “portfolio recalibration” after near-term oversupply versus forecast. Microsoft then reiterated their intent to spend big on AI infrastructure in 2025.

Four months later, Amazon Web Services withdrew a planned data-center campus in Louisa County, Virginia after intense community resistance (two other AWS sites in the same county continued forward). In Minnesota, AWS suspended plans in Becker as state policy makers debated incentives and electricity-use tax credits. To a casual reader, that might look like whiplash: cancelations in the same news cycle as bullish forecasts of AI-driven demand.

Just a few of the AI-generated data center renderings from my LinkedIn feed, accompanying announcements of multi-gigawatt projects to be delivered using largely conventional construction methods.

If you’re only skimming the headlines, yes, this looks contradictory. But when you zoom in on the details, a pattern emerges: these appear to be short-term shuffles about where and when capacity lands (and how it’s powered), not a repudiation of the underlying need. Timing, location and power-readiness appear to be the big pain points driving lumpy execution in a market that still points up and to the right.

What’s Behind This Year’s Spate of Cancellations?

From the vantage point of developers and operators actually turning dirt, three forces dominate today’s risk and schedule:

Grid connectivity. Studies, load interconnection queues, substation upgrades, and long-lead utility gear still gate many timelines.

Supply chain. Generators, chillers, and especially switchgear can swing delivery by quarters, sometimes years.

Design churn. The AI server roadmap is moving fast enough that every new generation puts pressure on facility assumptions, such as power density, networking, and cooling. As I wrote in a recent article, it’s easy to underestimate how deeply the IT stack now dictates the building. We’re not just creating white space anymore; we’re purpose-building around the servers we deploy.

Our data centers now need to be purpose-built for the technology inside, but the technology is being revolutionized every twelve months. Case in point: the roadmap for the Grace Blackwell servers over a 36-month period.

You can see the consequence in project metrics. In our work and in the research we track, ~90% of projects have experienced delays over the past two years; average schedules extend by roughly a third compared with initial plans. And because compute-hungry workloads monetize immediately once power and capacity show up, the finance impact is brutal: every additional month can shave roughly 2 percentage points off the internal rate of return across the entire facility’s useful lifetime.

That economic pressure helps explain why “cancellations” often aren’t repudiations so much as re-sequencing: shifting from one geography to another with better power timing, from lease to self-build (or back), or from monolithic scope to phased scope that matches utility milestones and real demand. In other words, these are calendar and grid problems, not “AI demand was a mirage” problems.

What Changes When We Admit Execution is Lumpy

Once we accept that the macro curve is rising but the micro execution is jagged, an informed strategy becomes pretty clear:

Speed and adaptability become the defining success metrics. Projects that activate the first tranche of compute earlier start monetizing earlier; projects that can densify cleanly avoid re-platforming when racks jump from ~120 kW to the imminent 300–600 kW era.

Overbuilding looks less like prudence and more like risk. When developers pour concrete for tomorrow’s white space to “avoid a future project,” they tie up capital and bake in assumptions that may break with the next server generation. That’s a recipe for stranded value and avoidable obsolescence.

Phasing beats monoliths. If power arrives in steps, if customer commitments arrive in steps, and if technology certainly arrives in steps, then your facility should arrive in steps too.

A New Data Center Typology for an AI World

Renderings of a three-phase build-out using Flexnode’s factory-built compute modules. Each subsequent phase is triggered and defined by upgrades to available power, new business requirements and the latest technology at the time of the expansion (source: Flexnode).

This is the context in which our team at Flexnode has been advocating and building a different model: rapidly deployable, factory-built modules that aggregate into full campuses over time. The goal isn’t novelty; it’s to translate uncertainty into option value. Here’s the shape of it:

Start small, earn early, scale cleanly.

In the case study shared above, the grid could eventually support ~144 MW of critical IT load, but only a fraction of that was energizable near-term, and the business case didn’t justify full build-out on day one anyway. We mapped Phase 1 at ~32 MW to land revenue now, positioned for Phase 2 to ~90 MW when power and demand matured, and reserved the full footprint for Phase 3, without freezing today’s capital into tomorrow’s guesswork.

Purpose-built modules, not generic boxes.

Modules aren’t just shipping containers with servers. They’re engineered to current reference architectures (e.g., Grace Blackwell era, “Rubin”/“Rubin Ultra” in view), with liquid-ready thermal backbones (CDUs, warm-water headers, quick-connect manifolds), electrical headroom (busway spines, spare breaker positions), and network fabrics that scale pod-by-pod. That means a block installed this year can densify as SKUs evolve, without re-drawing the entire site.

District thinking at campus scale.

Rather than a single monolith, we treat the site like a district energy system: modular compute blocks tied into shared power and cooling plants. As the workload mix shifts, we re-allocate capacity across the campus; as parts of the estate age out, we rehabilitate a tranche without slowing the rest. That’s how we avoid the “cliff” of end-of-life and keep the campus serving ongoing business needs.

Siting agility.

Because modules are factory-built and pre-commissioned, we can land them in non-traditional footprints (including sites with modest initial power) then scale with utility milestones. The benefit isn’t just speed; it’s the ability to make go/no-go decisions later, when the demand signal is real.

A design that accepts change as a requirement.

I often show a timeline with a conventional “18-month design + 24-month construction” arc and then lay three GPU cycles on top. It’s almost comical: by the time the building is halfway through construction, we’ve moved from one generation to the next and the next. The pace of traditional building delivery is generally incompatible with the pace of AI. Our answer is to invert the risk: build the pieces that are certain (site services, substation, shared plants), and keep compute capacity in swappable, phase-addressable blocks.

What This Approach Unlocks

Speed-to-power and time-to-revenue.

The fastest route to positive IRR is getting live sooner. If every “extra month” dings IRR ~2 percentage points, then compressing the first energization by even a quarter is enormous. A module that’s liquid-ready, electrically elastic, and pre-integrated with your controls stack doesn’t just shave weeks; it trims risk in the riskiest part of the schedule.

Capex deferral without painting yourself into a corner.

In place of the “build 200 MW now because we’ll need it later” reflex, you build what you need when you need it, and only commit the next tranche when the workload and power are real. You avoid stranded building systems that won’t match the next rack’s thermal profile.

A healthier relationship with the GPU roadmap.

When Jensen Huang puts the next three years of server architectures on a slide that show densities driving toward the hundreds of kilowatts, that’s not a reason to freeze; it’s a reason to design for non-disruptive densification. Thermal modularity and electrical headroom turn the roadmap into an upgrade plan, not a rebuild plan.

Portfolio flexibility (self-build and lease can coexist).

Large platforms constantly rebalance self-build vs. lease. A standardized, modular typology lets you do both on the same playbook, so changes in corporate strategy don’t force you back to square one. The “cancellations” making headlines in 2025 often reflected precisely this kind of rebalancing, local approvals and utility gating, not design obsolescence.

Comparison of a traditional, monolithic data center lifespan with one unlocked by Flexnode’s modular solution. In the case of the latter, initial tranches of compute power can be brought online earlier, the facility can be scaled up as needed, and the useful life of the campus can be extended indefinitely through tactical, continued renewal (source: Flexnode).

The Next Demand Wave: Inference Wants a Fabric, Not a Fortress

A final point about where the market is going. Training has dominated our mental model for the past two years: giant clusters, giant halls. But inference is now breaking out in ways that reward proximity and privacy:

Latency: Users expect sub-100-ms experiences for interactive apps and copilots embedded in workflows. That pushes compute closer to the user.

Bandwidth: Moving tokens and embeddings across continents is expensive. The economics favor regionalization of certain inference footprints.

Data security and sovereignty: Vertical-specific workloads (healthcare, financial services, public sector) bring jurisdictional requirements that argue for distributed, compliant nodes over a single hyperscale campus.

Put those together and you don’t just want a big box; you want a dispersed fabric of compute you can actually deploy - quickly, predictably, and in right-sized phases - then knit together with orchestration. The same modular, liquid-ready, electrically elastic typology that de-risks today’s lumpy execution is the best way to arrive early for that inference wave and scale with it, market by market.

That’s why I keep coming back to this: flexibility, speed, and adaptability are the defining success metrics now. If cancelations and pauses shook your confidence, look again. They’re reminders that the winners will be the teams who can land the first megawatts early, densify without drama, and scale as the grid and GPU technology allows. The market is still up-and-to-the-right; the execution is lumpy. Let’s build like we know that.

Next
Next

Reframing an Asset: Vacant Office Space for High-Density Compute