DC Requirements Translator
Helping engineering teams translate complex client requirements into actionable technical specifications.
The problem
A hyperscaler hands a data-centre project a set of requirements — rack density, power redundancy, cooling type, floor area. None of it obviously translates into what actually matters for the building: the structural loads, the electrical service, the cooling and water infrastructure.
Working that translation out early — before design starts — is slow, manual, and easy to get wrong. And redoing it for every "what if we went denser?" scenario is slower still.
Research
The friction wasn't the maths.
It was the translation.
Turning one specialist language — an IT spec — into another, the civil and structural design of a building, is expertise that usually lives in one experienced engineer's head. I don't have that background, so I worked with someone who does: a civil and structural engineer working on data-centre projects, who brought the real problem and fed me the domain detail.
I sat with how he reasons — from rack density and redundancy to the loads, service and cooling the building has to carry — and treated that reasoning as the thing to build. My job wasn't to become the engineer; it was to encode how he thinks so the translation stops living in one head.
The design approach
A tool that turns the client's inputs straight into design impacts:
Pick the hyperscaler, kW per rack, N / N+1 / 2N redundancy, air or liquid cooling and floor area, and it returns a design-impact summary — structural load, electrical service, cooling capacity and water flow — plus a side-by-side comparison of density scenarios. The decisions behind it:
Constrained inputs, not a blank form
Every input is a considered choice — the real parameters an engineer works with. The tool guides the user through the decision instead of asking them to know the format. Encoding the domain's actual vocabulary is what makes it usable by the people it's for.
Scenario comparison as a first-class feature
The real job isn't computing one answer — it's comparing options. A 40 kW/rack layout versus 90 kW/rack changes everything downstream, so the tool puts those scenarios side by side rather than making you run it twice and hold both in your head.
Output is design impacts, not just numbers
The results are framed for a civil and structural audience — loads, service requirements, capacities — and paired with plain-English build-risk notes, because the point is to make the requirements actionable for the people designing the building, not to hand them a spreadsheet they still have to interpret.
Screens
Captured from the live MVP — illustrative inputs, not a real project.
Technical implementation
The tool is a lightweight web app — the value isn't the infrastructure, it's the domain model inside it.
The decisions that mattered technically:
The engineer's reasoning, encoded as a model
The IT-spec-to-building translation — density and redundancy into structural load, electrical service, cooling capacity and water flow — is a set of rules and factors I built from how the engineer reasons. The domain logic is the product; the UI is just how you reach it.
A scenario engine, not a single calculation
Rather than compute one answer, it recalculates the full impact set for each density and lays them side by side, so "what if we went denser?" is one glance instead of a re-run you hold in your head.
A serverless route, not a platform
The model runs in a single Next.js serverless API route — no database, no persistent infrastructure to stand up. An engineer can try scenarios with zero setup, and the whole thing stays instant and cheap to run. The goal was to prove the idea and the model quickly, not to build infrastructure before it had earned it.
Outcome
It's an early MVP, built with the engineer to test feasibility and impact analysis — a shared tool for sanity-checking density scenarios early, before design work begins. The point it proves matters more than its size: an unfamiliar, highly technical domain became usable software by encoding one expert's judgement.
What I learned
This is the clearest proof of the thing I care about most: I can get up to speed in a highly technical, unfamiliar domain quickly — by sitting with the expert and encoding how they think.
The value is the translation, not the maths.
An early MVP, built with a data-centre engineer to test feasibility and impact analysis. Inputs shown are illustrative, not a real project.