Six months to the first requirement

For a worked requirement-to-test handoff, use GB300 acceptance evidence.

Twenty thousand GPUs. Liquid cooled. A network that has to do IPv6. Nobody involved had built one quite like it before, which in this market is not a warning sign, it is Tuesday.

The first sensible question is: what are the requirements?

The customer did not know.

Not "the customer was being difficult". Not "the customer was holding back". They genuinely did not know. They knew they needed a large GPU cluster, and they knew roughly how large, and past that the answer was that this is what they were paying somebody else to work out.

Six months went by. Not designing anything. Getting a decision on what was being asked for.

In the end the supplier wrote the customer's requirements for the customer. Around two hundred of them. The customer read them, agreed those were indeed the requirements, and the project moved on.

The architecture took most of another six months.

Then the build phase discovered the power was not going to be there.

This is the normal project

If you have done one of these, you already recognised the shape three paragraphs ago. If you have not, this is the part worth sitting with: nothing in that story is a scandal. Nobody was incompetent. Every individual involved was good at their job.

The customer could not specify a system they had never operated. The supplier could not start until the customer specified it. Both were behaving reasonably and the calendar did not care.

Why nobody could just pick it up and do it

Here is the thing that surprises people who have not worked inside one of these bids.

The network engineer owns the network, and is excellent at it. The storage engineer owns storage. The compute specialist owns the racks and trays. The cabling contractor owns cable. Every one of them is genuinely good, and every one of them will give you a precise, defensible answer about their layer.

None of them owns the whole.

And the whole is what the customer is buying. Somebody has to go from the storage to the GPU to the fabric to the power envelope, make it cohere, and then put their name on it. That last part is the one that stops people. It is not a skills problem. It is that signing your name to a system you cannot personally verify end to end is a genuinely uncomfortable thing to do, and most sensible engineers decline.

So the work waits for the one person willing to sign.

Speed is the differentiator, and it is close to the only one

Every operator in this market has access to the same GPUs. The same fabrics. The same storage vendors. The same models. The same power utilities, more or less, and the same data centre builders.

Everybody knows how to build a data centre. Everybody knows how to land servers and lay cable. The gap nobody talks about is the one between a hall full of humming, connected hardware and an actual token coming out of the other end.

Ask a data centre operator what your network should look like and you will get a confident answer about switches and topology. Ask whether it is the right network for training a large model and the confidence goes somewhere else.

Working that out takes six months to a year. That is if you are small and fast. Being small and fast is not the disadvantage here, it is very nearly the whole advantage, and it is worth being deliberate about protecting it.

What changes when the first pass takes a day

You can get this wrong just as thoroughly with software as without. That is not the pitch.

The pitch is when you find out.

Do it the usual way, with spreadsheets and a shared drive and diagrams that live in four different tools, and you discover the missing dependency in month three. Sometimes month ten. By then the number is in a proposal, the proposal is with a customer, and the correction is a conversation you have to have rather than an edit you get to make.

Put the parameters in and generate the thing on day one and you find out on day one. Even when the first design is wrong, and the first design is often wrong, being wrong on day one is a completely different category of problem to being wrong in month three. On day one it is a question. In month three it is a change order.

An RFP lands. Nobody yet knows what the network looks like. You know roughly the GPU count, roughly the storage, and that it is training rather than inference. That is enough to generate something and start arguing with it.

You might never open the software again on that deal. You would still have done in the first week what otherwise happens in the third month.

The starting checklist is the NCP requirements self audit. Every item names its NVIDIA requirement ID.

For why a compiled first pass is repeatable, read Ask a model twice.

The uncomfortable version

The reason this matters commercially is not efficiency. It is that in a market moving this fast, the organisation that can put a defensible architecture in front of a customer in ten working days is competing against organisations that take a quarter, using the same GPUs, for the same customer.

That is the entire gap. It is not a technology gap and it is not a capital gap. It is a design throughput gap, and it is the one thing in this market you can actually close this year.

Your first AI factory bid should not look like your first.

A note on this piece. The project above is composited from real work, with the customer, the supplier and the site deliberately unnamed. The people involved are still in the market and the commercial relationships are live. The shape of it is what matters, and anyone who has run one of these bids will recognise the shape.

The Bid Clock sets out what we deliver on days one, three, seven and ten.

The public release briefing explains the scope of the compiler behind that delivery.

The brief

How Neon fits your AI factory delivery pipeline

Nine pages for the people who sign: where Neon sits in an enterprise AI factory delivery pipeline, what it owns, what it never touches, and the three questions executives ask. Sent as a PDF.

The Neon briefings explain the design and delivery choices behind the package.