Where Are the Hundred Thousand?

The gap between a working prototype and a production fleet is an engineering-systems problem before it is a factory one.

In August 2025, the Pentagon's Replicator initiative reached the deadline it had set for itself two years earlier. The target was thousands of autonomous systems in the field, funded with about a billion dollars across two fiscal years. The Congressional Research Service put the number fielded at hundreds.

The stated reasons were the ones you would expect. Some systems glitched when they were integrated with existing command structures, some were unreliable, some were so expensive or so slow to manufacture that nobody could buy them in the quantity the program was designed around. And the Pentagon struggled to procure software capable of commanding large numbers of different drones at once, which was close to the entire premise of the thing.

That last reason is the one worth sitting with, and we will come back to it.

The same shape shows up well outside defense. Electric aviation spent the better part of a decade and several billion dollars on aircraft that flew, credibly, in demonstration. Lilium filed for insolvency twice inside five months and ended up scrapping prototypes, with roughly $1.5 billion in equity written off. Volocopter went insolvent in December 2024 after burning through more than 600 million euros. Rolls-Royce closed its advanced air mobility division, and Airbus paused the CityAirbus NextGen demonstrator. The aircraft flew well enough; the fleets never arrived.

We are living through the largest hardware renaissance in fifty years. There have never been this many drone companies, robotics companies, launch companies, electric aircraft companies. Defense departments now run open bake-offs where a four-year-old startup flies its hardware against a prime in a field, and the startup wins. Those wins are genuine. What almost none of these companies have produced is a fleet.

The factory answer is correct and incomplete

Ask the industry why, and the answer comes back fast: manufacturing is hard. Plenty of companies can design a compelling product and far fewer can produce it at the scale required. Scaling drones, in that reading, is a manufacturing problem.

This is true, and it is downstream of the actual constraint.

Factories are a solved category of problem in the sense that matters to a founder: they are expensive, they are slow, and they can be bought. Capital finds contract manufacturers, and contract manufacturers hire industrial engineers. The path from no factory to a factory is long and well understood, and there are people who do nothing else for a living.

What cannot be bought is the ability to say, on a given Tuesday, which version of the design is authoritative, which requirements the current build satisfies, which of your seventeen field configurations inherit a change made to a shared subsystem last week, and what breaks if a supplier moves a mounting point by ten centimeters. That knowledge is not a factory input. It is the thing the factory is supposed to be executing against, and in most programs it does not exist in any retrievable form. It lives in documents, spreadsheets, email threads, and the memory of four senior engineers.

You do not discover this at the prototype stage, because at the prototype stage it is not a problem worth solving. One product, one configuration, one team, one room. The information fits in people's heads because there is not much of it and it only has to be right once.

What multiplies between one and one hundred thousand

The prototype has to be correct once, on the day of the demonstration. A production program has to be correct continuously, across every unit, while the design keeps moving under it. Field data comes back. A supplier goes end-of-life on a component. A customer in a different country needs a different sensor package to satisfy a different regulation. A software update changes the thermal profile, which changes a margin, which invalidates a test result nobody thought to re-run.

And each of those changes has to be evaluated not against one product but against every variant currently alive. This is where the arithmetic turns. Adding a mission variant does not add one product's worth of engineering work. It adds one product's worth of engineering work multiplied by every requirement, test, parameter, and interface that variant shares with the others, because every one of those shared items now needs a decision about whether the change applies to it.

Most teams handle this by making a copy. A new flight test gets its own copy of the requirements spreadsheet, and a new customer configuration gets its own folder, so fifteen tests produce fifteen spreadsheets. Then a base requirement changes and it has to be applied fifteen times, by whoever remembers, and the authoritative version becomes whichever file was saved most recently.

That is the only available move when the underlying data has no structure capable of holding variation. And it is why the Pentagon could not find software to command large numbers of different drones. Different is the expensive word in that sentence. Managing many identical things is a logistics problem; managing many related but non-identical things is an information problem, and nobody had solved that one in a form the program could buy.

Where the cost lands

There is a well-documented reason why unresolved engineering questions get more expensive rather than merely later.

A NASA Johnson Space Center study measured the cost of correcting a requirements error at each phase of a project's life. Set the cost of fixing it during the requirements phase at one unit. Fixing the same error during design costs three to eight units, during manufacturing seven to sixteen, and during integration and test twenty-one to seventy-eight. Once the system is in operation, the range runs from twenty-nine units to more than fifteen hundred.

Scaling a program is, in practice, the act of pushing every decision you have not yet reconciled into a later phase. If you cannot tell which requirements a variant satisfies, you find out during integration. If you cannot see that a supplier change invalidated a test, you find out in operations. The multiplier is not a metaphor. It is the reason a program that looked six months from production spends three more years there.

The aggregate picture is visible in the public numbers. GAO's 2026 weapon systems assessment found the average time to deliver a capability had grown past twelve years, across a portfolio of major programs the Department of Defense plans to spend more than $2.4 trillion on. Forty-six of seventy-two programs reported cost increases totaling $122 billion. These are organizations with unlimited access to factories.

The coordination layer is a PDF

Between companies, it gets worse, because the medium of exchange is still a document.

A battery supplier described what happens when their OEM sends a revised order. It looks identical to the previous one. One dimension has moved ten centimeters. If that change goes unnoticed, the line needs a new ten-million-dollar robot to accommodate it. So the supplier's most experienced engineers spend days reading a thousand-page specification against the previous thousand-page specification, hunting for the delta by eye.

A warship builder described a design review that takes six months, because a two-line change obliges seventeen people to re-read the entire document to work out whether the two lines touch anything they own.

This is how the most advanced manufacturers in the world coordinate with their supply chains in 2026. PDF and email. Every tier of every chain, doing manual diff on prose. Multiply that across a supply base of dozens of suppliers per program and the twelve-year average stops being mysterious.

The analysis cycle is the constraint

Underneath all of it sits a throughput mismatch that gets worse the faster you go.

A program generates data as it runs: analyses, requirements, test plans, test results, field telemetry. Modern programs generate far more of it than earlier ones, because sensors are cheap and test cadence has gone up. What has not gone up is the rate at which a team can put that data in conversation with the design it came from.

When a test cycle runs weekly and the analysis cycle runs monthly, the program falls further behind every week. Not because anyone is idle, but because the evidence that would retire a risk is sitting unread. Risk accumulates invisibly, and it is paid later, in rework, in wrong orders, in a subsystem that has to be requalified after tooling has already been cut.

This is what people mean when they say systems engineering is too slow, though it is usually the wrong way to say it. The engineers are not slow. The analysis loop is longer than the generation loop, so the picture of the product is always out of date, and every decision made against a stale picture is a decision that may have to be made again.

How do we fix this

None of the above is fixed by a better factory, and it is not fixed by a faster CAD tool or a larger team either. Adding engineers to a program whose information is unstructured adds coordination cost roughly as fast as it adds capacity.

What would have to be true is more specific than that.

Engineering information would have to be structured as connected data rather than documents, so that a change to a requirement is a change to an object with known dependents, not a change to a paragraph that seventeen people have to read.

Variation would have to be a property of the data model rather than a filing convention, so that a fleet of configurations can share one source of truth instead of drifting apart as copies. 

Change would have to propagate itself, announcing what it touched at the moment it happened rather than waiting for a review to discover it.

And analysis would have to run continuously against that structure, at the rate the program generates evidence, rather than in a batch job that finishes after the next test has already flown.

How a company manages engineering information decides what that company is able to build. Talent and capital are both abundant right now; neither is the binding constraint on a drone company that has already won its fly-off. The hundred thousand units are missing because the information layer underneath them was built for products that shipped once, and today's products never stop shipping.

That layer is what Trace.Space is building toward.

‍