"Buy the biggest box your budget allows. You'll grow into it."

I hear a version of that sentence in most first conversations about AI infrastructure, and I'd like to argue with it in public.

The invoice arrives before the growth

It sounds prudent. It isn't. Headroom you can't justify is a purchase cost, a power draw, a cooling burden, and an operating obligation that starts billing the institution on day one. Growth might arrive someday. The invoice already has.

What the biggest-box rule hides

The deeper problem with the biggest-box rule is what it's concealing. If nobody can state the expected queue, the peak hour, the response target, and the trigger for expansion, maximum capacity becomes a way to skip the measuring. That's uncertainty rendered in metal, and we treat it as a symptom.

Sizing starts with the work

Run the sizing conversation in the other direction. Start from the work: how many people hit the system at once, how big their documents run, how fast an answer has to come back, which models earned a place during evaluation, and what must keep working when a component fails. Those answers frequently point at a smaller machine than the buyer expected, and that's not a disappointment. Good. Somebody measured the job before pricing the machinery.

A bounded first deployment disciplines everything

A bounded first deployment also disciplines everything around it. The institution picks one owned workflow and baselines it. Staff learn a single system instead of absorbing an estate. Security reviews a surface it can walk in an afternoon. Utilization becomes a fact on a graph rather than a guess on a vendor slide, and expansion's easier because the threshold was agreed in writing beforehand.

When large is the honest answer

None of this bans large footprints, and I don't want it read that way. A shared service with known concurrent demand, a research program with measured batch loads, or a regulated environment that needs redundancy from the first hour can justify serious hardware. The rule I hold is narrower: no larger than the evidence requires, no smaller than the service obligation permits.

Why there's no menu on this site

It's also why there's no standing menu of boxes on our site. Menus invite shopping by the seller's appetite; specifications don't. Discovery makes the workload, the facility, the governance, and the acceptance tests do the sizing instead.

So when the biggest-box advice shows up, we counter with two written questions. What concurrency did you assume? What threshold triggers growth? Vague answers there tell you more about the quote than the spec sheet does.

Summary: Right-sizing AI infrastructure starts from the work, not a hardware ceiling. An oversized system bills for power, cooling, and idle capacity from day one, and a maximum-capacity default often hides discovery nobody did. Measure concurrent users, document sizes, response targets, and the trigger for expansion first, and the honest specification is frequently smaller than the buyer expected: no larger than the evidence requires, no smaller than the service obligation permits. Large footprints are right when known concurrent demand, measured batch loads, or required redundancy calls for them. Before approving a purchase, ask for the concurrency assumption and the expansion threshold in writing.