A working demo is not a product, and the distance between the two is where most deep tech money and most deep tech years actually go.

At every deep tech event I have been to, somebody shows a working demonstration. The thing runs. The measurement comes out right. The room is impressed and the founder is asked when it ships, and the answer is next year.

It is not next year. It is usually two or three, and a meaningful share of these never ship at all, and the reason is a phase of work that is invisible from the outside because it produces nothing demonstrable.

I hit a compressed version of this on my own protocol translation work, which I assessed at Technology Readiness Level 4 and would assess the same way again. TRL 4 means validated in a laboratory environment. Deployed systems are TRL 8 or 9. The distance between those numbers is where projects die.

What the demo actually proved

A demonstration establishes that the physics or the algorithm works, once, under conditions chosen by the person demonstrating.

That is genuinely valuable and it is the necessary first step. It is also a small fraction of the total, and the reason the fraction is small is that a demo is allowed to assume things a product cannot.

The demo runs on the one unit that was built and tuned. It runs at room temperature. It runs while the person who built it is present, and that person makes small unconscious corrections nobody records. It runs on inputs within the range it was developed against. It runs for the duration of the demonstration. It does not have to be manufacturable, serviceable, certifiable or explicable to a stranger.

Remove those assumptions one at a time and each removal is months of work.

The phases people skip in the plan

From one unit to any unit. Your prototype works. Build ten from the same drawings and some will not. Component tolerances stack. The transistor you hand-selected has a distribution. The mechanical fit that worked with the part you filed does not work with the part as specified. Yield is the discovery that your design assumed the typical value of every parameter simultaneously.

This is where design for manufacture starts, and it usually means partial redesign, because the choices that made prototyping fast are frequently the choices that make production impossible. Hand-soldered parts, a machined bracket that should be a casting, a fixture that only the founder can align.

From works to keeps working. Reliability is a statistical property measured over time and populations, and there is no shortcut for it. Accelerated life testing compresses the clock and does not eliminate it. Thermal cycling, vibration, humidity, and if the environment is harsh, salt fog and shock and altitude.

Every one of these finds something. Solder joints crack under thermal cycling. Connectors back out under vibration. Firmware that ran fine for an hour has a counter that overflows on day 24. That last class of bug is the one nobody finds before shipping, because finding it requires running for 24 days and nobody ran for 24 days.

From working to compliant. Depending on the domain: electromagnetic compatibility, safety certification, environmental standards, and in regulated sectors a documentation trail that is larger than the engineering effort. In defence and aerospace, qualification against military standards involves testing regimes that can cost more than the development did.

Certification cannot be parallelised much and it cannot be started late, because it frequently forces design changes. A product that fails EMC testing at the end goes back to layout.

From compliant to supportable. Someone who is not you has to install it, operate it, diagnose it and repair it. That means manuals, error messages a stranger can act on, diagnostic access, spare parts, a support process, training material, and a plan for the component that goes end-of-life in three years.

This work is entirely invisible in any demonstration and it is a substantial fraction of what makes a product a product.

Why it gets underfunded

The people involved are not naive. The structure produces this.

Funding follows demonstrable milestones, and this phase has almost none. You cannot show a steering committee a reliability qualification campaign in a way that feels like progress. You can show them a demo, which is why the demo gets built and the qualification does not.

Estimation is genuinely hard here in a way it is not for the demo. The demo has a known endpoint. Reliability work has an endpoint defined by what the testing finds, which by construction you do not know in advance.

The skills are different and less prestigious. The person who builds a novel demonstration is a research engineer. The person who takes it to production is a manufacturing or systems or test engineer. The second is harder to hire, less celebrated, and frequently paid less, and no founder’s instinct says the next hire after the breakthrough should be a test engineer.

And there is an incentive to keep demonstrating. Another demo raises another round. Qualification testing does not. The capital rewards the visible half of the work, so the visible half is the half that gets done, and the invisible half is what determines whether there is ever a product to sell.

What the ones who get through do

They assess honestly. Use the TRL scale, or something like it, and apply it strictly. TRL 4 is a laboratory validation. Calling it TRL 6 because the demo was impressive corrupts every downstream plan. I put my own work at 4 in public and the discipline of that was useful.

They build the second unit early. Not the tenth. The second, built by someone else from the documentation, is the cheapest possible test of whether the design exists outside one person’s hands. It always fails the first time and the failure is information you want in month three, not month eighteen.

They start environmental testing before the design is finished. Partial testing on a partial design finds the class of problem, which is what you need. Waiting until it is done means finding problems when changing them is most expensive.

They budget the phase explicitly. As a named line, with a schedule and an owner, at something like two to five times the demo effort depending on the domain. The number will feel wrong when you write it and approximately right when you finish.

They hire for it. One person whose job is making the thing manufacturable and reliable, hired before you think you need them.

The honest framing

The demo is the beginning. It proves the thing is possible, which is necessary and which most ideas fail, so it is a real achievement.

The eighteen months after are where the product is. That period generates no impressive images, no announcements, and very little that photographs well. It is where the work is, and treating it as the boring bit after the interesting bit is the most reliable way I know to end up with a very good demonstration and nothing else.

So the question I care about when I look at a deep tech team is not whether the demo works. Demos mostly work. It is whether anyone in the room has costed the eighteen months, named an owner for them, and is willing to say the number out loud.

Related: