Spec-to-delivery OS for AI campus builders turning tenant GPU designs into bankable power, cooling, and network packages.

1. Capital is already rewarding operators that own the full campus stack, so development teams have budget and board pressure to professionalize delivery.
2. Power, construction, cooling, and cloud operations are converging inside one operator, so the most fragile failure mode is now the handoff between disciplines.
3. Land, electricity, cooling, and networking are explicitly named as gating inputs, which means late spec drift can strand the entire campus schedule.
4. OpenAI- and Oracle-linked campuses raise the penalty for missed design freezes, because a single tenant expects hyperscaler-grade certainty before procurement and financing close.

Catalyst. Crusoe's fundraising talks and the Abilene example show money and demand rushing into campus-scale AI projects where power, land, cooling, and networking all have to line up at once, making cross-discipline spec control an urgent bottleneck.

The product becomes the shared operating layer between the anchor tenant's cluster spec and everyone who must build against it. It ingests tenant requirements, utility assumptions, cooling selections, network topology, EPC milestones, and procurement dependencies, then produces one auditable basis-of-design with variant comparisons and conflict alerts. Teams use it to issue synchronized vendor packages, quantify the schedule and capex impact of every spec change, and keep lenders and tenants aligned on what is actually buildable. Over time, the company builds proprietary data on which design choices, vendors, and sequencing patterns keep AI campuses bankable and on schedule.

What's different. Generic BIM, PM, and DCIM tools each see one slice of the problem, and consultant-led owner's-rep workflows do not create a reusable source of truth when tenant specs change weekly. This company owns the spec-freeze layer earlier than DCIM and narrower than full construction software, translating AI cluster assumptions into synchronized engineering and finance artifacts. Its moat compounds through a dataset of design variants, vendor response times, and change-order outcomes that general construction platforms and point cooling tools do not capture.

Jobs to be done

flowchart LR
  Buyer[AI campus developer] --> Pain[Cross-discipline spec drift]
  Pain --> Product[Spec-to-delivery workbench]
  Product --> Outcome[Faster bankable campus procurement]

Executive takeaways

• The buyer pain is real: AI-campus developers now have to freeze a financeable basis-of-design across power, cooling, network, and procurement while anchor-tenant requirements are still moving.
• The beachhead is narrow but valuable. A small set of North American developers and hyperscalers are building multi-hundred-megawatt campuses where one bad design revision can ripple into utility work, OEM packages, and financing milestones.
• Incumbents already own adjacent layers such as BIM, construction execution, document control, and DCIM, so the startup only wins if it becomes the earliest spec-to-delivery control point rather than another generic project tool.

Market definition

Workflow software for AI-campus preconstruction and design-freeze: the layer that translates anchor-tenant cluster requirements into a shared, auditable basis-of-design across power, cooling, network, utility, vendor, and financing workstreams before procurement is fully locked.

Customer and buyer

Primary users are chief development officers, delivery VPs, owner's reps, and program leaders at AI-campus developers or owner-operators managing a live 50-200 MW phase. The economic buyer is usually the development or delivery executive who owns basis-of-design risk, milestone certainty, and the credibility of procurement and financing packages.

Buying triggers

• Capacity is increasingly committed before delivery, so tenant spec changes collide with already-reserved power, land, and construction slots. [1][4][5]
• Power-first site selection and long electrical-equipment or interconnection timelines make any basis-of-design re-open disproportionately expensive. [2][3][6][15]
• High-density liquid-cooling and rack-power decisions now hard-code multiple facility, utility, and vendor choices much earlier in the project than traditional data-center builds. [21][22][23][24][25][26]

Willingness to pay

Buyers already face billion-dollar campus economics, multiyear power and equipment bottlenecks, and financing packages that depend on schedule certainty. In that context, a dedicated control layer is economically plausible if it can prevent even one major re-freeze or preserve one funding milestone. [2][27][28][30][33]

Category dynamics

Growth signal 17% CAGR

Validation signals

• Crusoe’s Brookfield credit line and its Blue Owl / Primary Digital joint venture show that capital providers are already financing vertically integrated AI-campus delivery platforms.
• CoreWeave’s OpenAI agreement and follow-on debt facility show that dedicated AI infrastructure contracts are already large enough to support specialized workflow tooling around them.
• Near-record-low vacancy and a 35 GW North American construction pipeline indicate that developers are operating in a hurry-up, commit-early environment.
• Vendor reference architectures for 132-142 kW racks suggest the technical stack is moving from experimental to repeatable, which makes a coordination layer easier to standardize around.

Regulatory & technical constraints

• Primary markets are dealing with grid connection waits that can stretch past four years, making power certainty a gating technical and regulatory dependency.
• Reliability bodies now treat large computational loads as a distinct systems problem, which raises the bar for observability, curtailment logic, and coordination with utilities.
• GB200/GB300-class densities require new liquid-cooling, power-distribution, and control assumptions that many legacy workflows were not designed to manage.
• Water transparency, local zoning, and community scrutiny can become critical-path constraints in clustered AI-campus regions.

The market is crowded with adjacent tools but not with purpose-built AI-campus spec control. Construction suites help downstream execution, Aconex and ProjectWise help document governance, and DCIM or vendor reference-design players help facility planning. The whitespace is the upstream layer that turns tenant GPU and redundancy requirements into synchronized power, cooling, network, procurement, and diligence artifacts before each change spills into the rest of the campus program.

Why incumbents do not win by default

• Construction suites. Procore and Autodesk help coordinate documents and execution, but they are not naturally the source of truth for AI-cluster assumptions or lender-ready design-change logic.
• Capital-project systems of record. Aconex and ProjectWise are strong at document control, workflows, and audit trails, but they start once project artifacts already exist instead of translating tenant compute specs into cross-domain campus scope.
• Mission-critical infrastructure and DCIM. Schneider, Vertiv, and similar vendors can define parts of the power and cooling architecture, yet they are vendor-centric infrastructure layers rather than neutral multi-party control planes for spec drift and financing alignment.

The strongest investor-ready version of this company is not a general data-center project platform; it is a spec-to-delivery control layer for owner-side teams trying to freeze a financeable AI-campus basis-of-design before EPC and OEM packages go out. The first customer is a North American developer or owner-operator with one 80-150 MW single-tenant phase, an anchor-tenant LOI, active bids out to power, cooling, and networking vendors, and a 2027 energization target. The MVP should ingest tenant cluster assumptions, utility constraints, cooling architecture, network topology, and milestone dependencies, then keep one human-approved baseline with quantified schedule and capex impact for each material change. GTM, pricing, and onboarding should all revolve around the same moment: a density revision or financing gate that forces the buyer to re-freeze design faster than spreadsheet- and consultant-led coordination can. Research supports real pain and credible willingness to pay because buyers are already underwriting billion-dollar campuses amid power scarcity, preleasing, liquid-cooling complexity, and financing pressure. The deliberate constraint is to remain an overlay above Aconex, Procore, Autodesk, Bentley, and vendor tools rather than trying to replace BIM, DCIM, or EPC workflows in year one. The business is attractive if it can land 3-5 live campuses at roughly $250k-$400k annual software value plus implementation and then expand into procurement, commissioning, and lender reporting. The main investor reservation is that the initial buyer pool is tiny and the research still leaves two crucial gaps: how often live programs actually re-freeze design and which function truly owns the budget for this category.

Problem

• Anchor-tenant capacity is increasingly committed before power, cooling, network, and utility assumptions are fully frozen, so one tenant revision can trigger rework across EPCs, OEMs, utilities, carriers, and financing materials.
• Today's workflow is fragmented across spreadsheets, BIM exports, email, owner's reps, and document-control systems that preserve records but do not keep one live basis-of-design synchronized across disciplines.
• Long interconnection timelines, high-density liquid cooling, and lender scrutiny make late spec drift economically dangerous because a bad re-freeze can delay procurement, financing releases, or energization on a hundred-million-dollar campus phase.

Solution

• Build a versioned basis-of-design workspace that ingests tenant cluster requirements, utility assumptions, cooling selections, network topology, and milestone dependencies for one live campus phase.
• Quantify the schedule and capex impact of each material change across power, cooling, and network domains, while keeping every recommendation human-approved, permissioned, and audit-linked.
• Export synchronized vendor, utility, and lender packets back into incumbent systems so the product lands as an upstream control plane rather than a new document silo.

Why we win

• The wedge is tied to a specific event when budget, urgency, and measurable ROI converge: an anchor-tenant revision or financing milestone that forces a rapid design re-freeze.
• An overlay architecture fits customer reality better than a rip-and-replace pitch because developers, EPCs, and owner's reps already run Aconex, Procore, Autodesk, Bentley, and vendor-specific tools they will not swap mid-program.
• Each deployment compounds proprietary data on spec drift, vendor response times, capex and schedule impacts, and packet-approval outcomes that broad construction or DCIM suites do not capture in one place.

Milestones

flowchart LR
  Wedge[Single-tenant AI campus wedge] --> MVP[Versioned basis of design MVP]
  MVP --> Proof[Faster design re-freeze and packet sync]
  Proof --> Expansion[Procurement commissioning and multi-campus expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• There must be enough live North American 50-200 MW single-tenant campus phases to support at least 5 production campus contracts by year 3.
• Development or delivery executives must fund an owner-side control layer at roughly $250k-$400k ARR without waiting for a broader platform replacement.
• Imported artifacts and lightweight integrations must be enough to prove value before the buyer demands full Aconex, Procore, Autodesk, or Bentley replacement.
• The product must cut basis-of-design re-freeze time by at least 25% and reduce package-sync errors on live campuses.
• Templates and outcome data from the first campuses must transfer into second phases, new campuses, or adjacent AI-infrastructure workflows before the beachhead saturates.

Open diligence questions

• How many material spec revisions per campus typically force package reissue, capex review, or financing escalation?
• Which role signs the first budget: Chief Development Officer, SVP Delivery, infrastructure-finance lead, or owner's rep?
• What minimum security, access-control, and deployment requirements must be met before buyers share tenant topology and power data?
• Which incumbent systems must be integrated for the first deployment, and can exports really substitute for deep integrations?
• Have lenders, insurers, or board committees actually required auditable design-change packets on live campuses?
• How likely are EPCs or incumbent project systems to absorb this workflow before the startup builds a durable data moat?

Model sanity

• Revenue engine. Base-case revenue comes from three paid design partners converting into five active campus phases by Q4Y3, with older accounts expanding from roughly $372K recurring toward the researched ~$0.4M annual budget.
• Must go right. The company must keep deployments overlay-first enough that the same 8-FTE team can support the fifth campus without adding another services-heavy hire.
• Model breaks if. If sales cycles slip by a quarter or buyers demand deeper incumbent-system replacement work, the downside case pushes cash toward the ~$0.6M floor even after the raise.
• Next-round proof. The next financing is justified once four production phases, one repeat referral channel, and the first procurement-or-lender upsell are visible before the Q4Y2 milestone.

Scenarios

Sensitivity

flowchart LR
  Accounts[Target AI-campus accounts] --> DesignPartners[Paid design partners]
  DesignPartners --> Contracts[Annual campus contracts]
  Contracts --> Expansions[Phase + module expansions]
  Expansions --> Revenue[Subscription + implementation revenue]
  Revenue --> GrossProfit[70% gross profit target]
  GrossProfit --> Cash[Runway]

Flags: The model still sits below the Rule of 40 in Y3 because implementation work and revenue concentration keep EBITDA margins negative even after reaching the SOM path. · Base-case customer counts assume no net logo losses through Y3 because within-account phase expansion offsets project roll-off; if campuses end sooner, revenue will miss plan. · Headcount stays flat at 8 FTE from Q4Y2 through Q4Y3, so the model depends on reusable packet templates and lightweight integrations actually shrinking implementation load. · Five active phases is a meaningful share of the modeled 28-campus beachhead SAM, so one lost reference account would have outsized impact on the revenue path.

• Small initial buyer pool. Only a limited number of teams are building first-wave single-tenant AI campuses today, so revenue could concentrate in a narrow segment. Mitigation: Start with high-ACV live programs, then expand the same workflow into retrofits, sovereign campuses, and lender diligence once the category is proven.
• Workflow trust gap. Development teams may resist relying on software for design decisions if source documents are incomplete or engineering ownership is unclear. Mitigation: Start as an auditable system of record with human-approved baselines and evidence-linked changes, not as an automated engineering sign-off engine.
• Incumbent stack encroachment. Construction suites, DCIM vendors, or EPC firms could bundle adjacent change-control features after the category becomes visible. Mitigation: Own the tenant-spec-to-financing workflow early, integrate with incumbent tools, and compound a proprietary dataset on AI-campus-specific change outcomes.