The $1M-per-day problem hiding inside every Data Center build.
It is not labor. It is not materials. It is not financing. It is the slow, manual coordination work that decides whether the project actually lands on time.

The $1M-per-day problem hiding inside every Data Center build.
It is not labor. It is not materials. It is not financing. It is the slow, manual coordination work that decides whether the project actually lands on time.
Three weeks before a switchgear install, a project engineer makes a phone call. The vendor confirms the unit will arrive eight weeks late. The engineer hangs up. The schedule was already tight. Now it is gone.
The electrical contractor starts reshuffling crews. The GC reforecasts the schedule. The operator on the receiving end of the build recalculates when their data center actually starts generating revenue.
Nobody on the project did anything wrong. The order was placed nine months in advance. The vendor confirmed a date. Someone updated a spreadsheet. Someone else did not see the update. The week slipped, then slipped again, and the only signal that something had gone wrong was a phone call three weeks before the unit was supposed to arrive on site.
This is the most expensive failure mode in mission-critical construction. And it is happening on almost every data center build in the country, right now, today.
The nuer nobody puts on a slide
In high-stakes construction, the opportunity cost of delay can exceed $1 million per day.
That figure surfaced this month in Engineering News-Record's Midwest "Tools of the Trade" spotlight, attributed to Benjamin Sack of 53 Stations. It is a clean way to frame something the industry has known operationally for years but has rarely put into dollar terms: the difference between a project that lands on time and a project that slips by a quarter is rarely about labor productivity or material cost. It is about how well the team coordinated the supply chain in the eighteen months leading up to install.
Multiply $1M per day across the dozens of long-lead items on a single mission-critical build, then multiply that across the hundreds of active data center projects in the Chicago, Dallas, Northern Virginia, and Phoenix corridors, and the size of the problem becomes hard to look away from.
Why this keeps happening
Procurement on a mission-critical build involves hundreds of equipment items, dozens of vendors, multiple subcontractors, design teams, and an owner all needing the same picture of what is arriving when.
The way most teams hold that picture together is the same way they were holding it together twenty years ago. Spreadsheets. Email chains. Phone tag. A handful of people in the middle trying to reconcile what the vendor said this week against what the vendor said last week against what the schedule needs and against what the field is going to do if the answer changes.
The work is not difficult. It is just relentless. Every confirmation requires a follow-up. Every follow-up requires a chase. Every chase requires another email, another call, another spreadsheet update. The procurement engineer ends the week having spent twenty hours on coordination tasks that produced no decisions, just the same picture refreshed.
And because the work is diffuse, the failure mode is invisible until it is not. The delivery slips quietly across three weeks of unanswered emails. The phone call surfaces the problem at the exact moment when there is no time left to do anything about it.
What changes when coordination runs autonomously
This is the problem Kaya was built for. Autonomous agents handle the supplier follow-up that humans used to handle manually. Schedule risk gets surfaced weeks earlier, before delays compound. Lead-time accuracy improves because the data is fresh, not stale.
The shift on the ground looks like this:
At Turner Construction, project teams using Kaya have reported zero day-of delivery surprises, 50%+ fewer manual follow-ups, late or unconfirmed deliveries identified two to four weeks earlier than before, and procurement and delivery logs generated ten times faster. Turner's PM Allison Kelly described it as moving from chasing information to acting on it.
At Suffolk Construction, Kaya now supports more than $1 billion in active project value. Procurement log creation that used to take days now takes hours. Engineers are getting more than five hours back per week, time that used to be spent on manual coordination and now runs autonomously in the background.
Across the broader customer base, including ARCO and Haskell alongside Turner and Suffolk, the same pattern holds. The value is not in any single dashboard. It is in the compounding effect of decisions getting made faster, with better information, earlier in the chain. The $1M-per-day risk shrinks because the moments at which delays can be caught get pulled forward by weeks.
The shift the industry is starting to name
What made the ENR piece worth paying attention to is not the feature itself. It is that an investor with a clear view across the construction technology landscape put a name on the category and made an argument the industry has been quietly converging on for two years.
The argument is that the next decade of construction AI does not get decided on the jobsite. It gets decided in the workflows that sit weeks earlier in the project: procurement, coordination, supply chain. The field tools of the last decade, robots, wearables, computer vision, all have a place. But the operational and financial stakes of mission-critical construction now sit upstream of the install. That is where autonomous coordination earns its keep.
Ben's framing in the piece is that the ROI shows up in four places at once: less manual procurement work, faster decision cycles, improved visibility, and fewer costly disruptions. Procurement has been undervalued for years because those wins were diffuse. Autonomous coordination makes them measurable.
Where this is heading
The data center pipeline is the forcing function. ENR's Midwest spotlight names 27 active projects in Illinois alone and 81 more planned. Sites like T5@ChicagoIV, with 20 buildings at 60MW each, represent the kind of capital deployment that turns procurement precision from a nice-to-have into a board-level concern.
The same dynamic is playing out across every market where compute capacity, hyperscaler demand, and grid constraints are colliding. The projects that get built on time will be the ones whose teams figured out how to remove the manual coordination tax from procurement. The ones that slip will be the ones still running on spreadsheets and phone tag, finding out about delays three weeks before install.
The phone call that surfaces an eight-week delivery slip should not be the first signal that anything was wrong. It should be a confirmation of something the system caught weeks earlier and the team has already worked around.
That is the shift. That is what we built Kaya for.
Thanks to Benjamin Sack and the team at 53 Stations, to Mike Ragogna, and to the editors at Engineering News-Record for naming this category clearly. The full "Tools of the Trade" Midwest spotlight is worth reading for the broader context on Chicago, Detroit, and Indianapolis as innovation corridors.
You can find the piece on enr.com/midwest/resources/SpecialAd.
Kaya is autonomous procurement coordination for mission-critical construction. To see how teams at Turner, Suffolk, ARCO, and Haskell are using it on data center and high-stakes builds, book a demo or reach out to the team directly.
© 2026 Kayapay. All rights reserved.


















