Before I build a data center optimizer, here is what the public evidence supports

What I am building

I am building an enterprise product for data center operators. It has two jobs: optimize compute and energy use, and help teams source spare parts. My working thesis is that one integrated product, with measured savings, can beat the point tools operators already buy. I have not built it yet, and I have no pilot data. This article covers what the public evidence supports about that bet, and how I plan to test it.

The utilization gap is widely reported, but its size is unverified

Average server utilization looks low. The Natural Resources Defense Council reports 12% to 18%, as relayed in a 2023 Sardina Systems blog post. I have not checked the NRDC report itself. Other researchers estimate about 10% (PowerNap study). According to a McKinsey survey cited by Forbes, and other sources, average server utilization is about 15% while reservation rates sit at 80%, so servers draw power and cost money without carrying the work they should. The Forbes article is dated 2015, and I have not seen the survey itself.

Power is the other pressure. Berkeley Lab’s 2024 report, as summarised by Energize Capital, says U.S. data centers used about 176 TWh in 2023, or 4.4% of U.S. electricity, and could reach 6.7% to 12% of U.S. electricity by 2028. I have not checked the Berkeley Lab report itself. These figures show the size of the pressure. They do not show what a product would save, and I have not built a savings model on them.

Maintenance is the third lever. A 2010 U.S. Department of Energy guide, as cited by Schneider Electric in a 2026 blog post, says up to 30% of preventive maintenance tasks may be unnecessary. I have not checked the DOE guide itself. Because it is more than fifteen years old, I treat it as a hypothesis to test on my own sites, not a current measurement. I have left out other maintenance savings percentages because I could not trace them to a primary source.

Parts supply is a separate question, and the evidence on it concerns new builds. A GPU infrastructure seller’s LinkedIn post says GPUs and HBM memory are sold out, with power transformers at a four-year lead time and cooling systems for 120 kW racks at a six-to-nine-month backlog. The same commentary says the companies that win are the ones that “figured out the supply chain 18 months ago.” These are new-build constraints, not measured spare-parts shortages in existing facilities, and the source is a social post, not a market study. I have not found data on spare-parts lead times for operators. For a 100 MW facility, construction typically runs $900 million to $1.5 billion, and electrical systems can account for around 50% of that build cost (industry cost article).

Incumbents already sell pieces of this

This is the first hard fact against my thesis. A hardware retailer’s 2026 DCIM buyer guide says DCIM software combines facility management and IT infrastructure monitoring, collecting data from servers, network devices, cooling systems, power distribution units and environmental sensors. DCIM and asset-management platforms cover monitoring, capacity planning and asset tracking. I have not checked individual vendors’ product pages, so I do not name them here.

Workload tools claim more. Sardina Systems (2023) says its FishOS platform can reach up to 50% server utilization through workload packing based on live resource data. This is a vendor claim, not an independent result. Nokia’s event-driven automation platform, introduced in September 2024 for AI-era data centers, claims savings of up to 40% in operational time and resources. Again, a vendor claim.

I have not found a source that measures how much efficiency headroom remains in existing facilities, so I will not assume large gains are waiting to be picked up.

The honest question is therefore not whether an integrated product is possible. It is whether one product, across compute, energy and parts, measurably beats the bundle an operator already runs.

The sale is slow

Enterprise B2B software sales typically take 9 to 18 months, and complex deals involving infrastructure changes can run past two years (industry sales-cycle guide). A Substack summary of Forrester’s 2023 B2B Buying Study, relaying HubSpot, reports the average enterprise sales cycle rose from 6.4 months in 2015 to 9.3 months. I have not checked Forrester’s primary report.

Several gates add time, as reported in secondary summaries. In SAP’s analysis of its own enterprise contracts over $500,000, 82% included formal proof-of-concept stages, adding about 2.4 months. Salesforce reports its enterprise clients spend an average of 3.2 months on security and compliance reviews. The 2023 Gartner CFO Survey, as cited in a secondary summary, found 73% of enterprises set extra approval thresholds for technology purchases above $100,000, adding roughly 45 days. Large organisations typically run formal procurement with predefined budget cycles, which lengthens decisions that miss a cycle. McKinsey research cited in a secondary summary finds 6 to 10 decision-makers in enterprise purchases, up from 5.4 in 2015.

These company-reported figures come from vendors and analysts whose primary reports I have not checked, so I treat them as signals, not settled numbers.

The pilot trap

One enterprise AI consultant reports that a three-week prototype produced a 40% efficiency gain on one line and led to a wider engagement. This is an AI consulting anecdote, not a data center case, and it comes from a social post. In another social post, a buyer’s previous consultant had pitched a $500K AI transformation roadmap; six months later the project was still in planning with no measurable results. I use these only as illustration. The sales-cycle figures above are the stronger evidence: a pilot’s proof has to survive a long, multi-gate buying process before it becomes revenue.

What changes in my plan

The evidence pushes me to narrow the thesis before I build the full suite:

• Start with one measurable line. Pick one cluster or one class of equipment, and measure its utilization, power cost and parts downtime before any change.
• Benchmark against the bundle. Compare results with the operator’s current DCIM and automation spend, not with an empty baseline.
• Prepare the security and data package before the pilot. A pilot that cannot reach production wastes the cycle.
• Offer SLAs I can actually meet. Promise measurement and response times, not uptime guarantees my product cannot control.
• Set a kill point. If the pilot shows no measured saving inside one budget cycle, I will not extend it to the full suite.

The pilot criteria above are the test this plan has to pass.

Read the full article, including the pilot criteria, at {{url}}.