Starting from a power usage list to understand data center delivery

I compared two options—building my own data center vs. buying Powered-Shell—and actually ran through both. Self-building from land acquisition to power-on takes at least two to three years; Powered-Shell is about getting the building, the power to the site, and network access ready first, and you fill in the IT equipment yourself. The Volta Infra campus product quotes 12 to 18 months to deliver power-ready, with projects in Karnataka and Tamil Nadu. Sounds convenient, but where exactly the boundary of "power-ready" lies is something you have to ask about item by item.

Powered shell refers to a newly built building designed specifically for data centers, including the physical structure, power to the site, and connectivity options, but not the main IT infrastructure. In plain terms, it's a bare shell plus power, with a spot left for network access. The UPS inside (the battery bank that kicks in during an outage), the cooling system, and the rack-level power distribution are mostly up to you. If you don't get this step clear, everything downstream goes wrong.

First, write your requirements into a table—don't just say "I want a few dozen racks." Open Feishu Base and create a new table. Set rack count and per-rack power as number types; fill rack count with 40 first, and calculate per-rack power based on GPU racks—don't think in terms of 5, just put 30 or above; total IT load uses a formula: rack count times per-rack power divided by 1000; redundancy uses a single-select filled with N+1 (one extra set, so one failure doesn't cause downtime); liquid cooling is a single-select yes or no; and leave a delivery time window as a date type. What you see is one row of data with a total IT load number—that number is the starting point for talking to suppliers, not the rack count. I got this wrong at first, asking with rack count, and the other side replied "this phase is 20MW"—the two sides didn't match at all, and the meeting was wasted.

Next, go through the delivery boundary checklist item by item. Ask the other side for a checklist, add a column in the table for "included" as a checkbox, and tick them off one by one. Focus on four things: who builds the line from the substation to the campus, whether UPS and diesel generators are included, whether the cooling system is included, and what the floor load capacity and ceiling height are. Once you've ticked through a row, you can see at a glance what's missing. From my testing, the easiest trap is understanding "powered" as "ready to install machines"—it's not; the shell is empty.

Then there's the site survey. Add a column for survey notes as multi-line text, and fill in four items on site: whether there's dual-feed incoming power, how far the substation is, whether there's outdoor space for chillers, and whether trucks can drive in. Don't think it's too basic—if any one of these four fails, everything calculated earlier has to be thrown out. I've seen a campus where power was fine but there was no outdoor space for cooling equipment—equivalent to a wasted discussion.

Acceptance terms must write "ready" as a quantifiable sentence: on a certain date, deliver a certain MW of IT load, dual-feed energized. Without that sentence, 12 to 18 months is just a claim.

Two more pitfalls to add. Unit confusion is the most common—when the other side says MW, it might include cooling, or it might count only IT load; a 20-30% difference is normal, so you must ask clearly which basis it's calculated on. The other is that the approval pace differs between the two states—don't schedule on the same timeline; Karnataka's process runs faster, so leave more buffer for Tamil Nadu.

Once this table is fixed, my requirement meetings with suppliers went from several rounds down to one. Team execution is key—who holds the table and who's responsible for updating it must be assigned to a person, otherwise it's dead within a week.

If you're really going to do this, take your own real power usage list, find three suppliers, ask for their delivery boundary checklists, and fill them into the same table. Once filled, look at them side by side—who doesn't include what becomes obvious at a glance. Don't talk price first; if you talk price too early, the boundary will always be fuzzy.