Every defense technology evaluation used to come down to one question: does the thing work? Can the drone fly, can the sensor see, can the model find the target in the clip the founder brought to the meeting. Fair question. Nothing matters if the answer is no.
But here’s what we’ve learned at UAX after enough of these evaluations: the demo almost always works. Defense founders are some of the sharpest people we meet, and they understand this perfectly by the time they’re in the room, the demo will work. The harder question is whether it will work in an environment that demands adaptation. By the time a technology reaches diligence, “does it work in a controlled setting” is usually a solved problem. The real risk has moved somewhere else entirely.
The question that actually predicts success now is uglier and harder to test: can this thing survive contact with everything around it?
Where defense technologies actually succeed or fail
| Stage | Outcome |
|---|---|
| 1 - The demo | Always worksControlled environment, founder in the room |
| 2 - Technical diligence | Usually passesBenchmarks, spec validation, model performance |
| ✕ Most diligence stops here | |
| 3 - Integration | High riskC2 systems, legacy infra, operator workflows |
| 4 - Field deployment | Most die hereReal operators, real environments, no controlled conditions |
| 5 - Scale | The goalRepeat deployability across customers without re-engineering |
Most diligence stops at step 2. The failure happens at step 3.
The Integration Layer Is Where Strong Technologies Die
Modern operations are not single systems. A mission pulls together sensors, comms networks, software layers, autonomy stacks, AI tools, and still, always human operators who already have a way of doing their job. No one component decides the outcome. What decides the outcome is whether data moves cleanly from one box to the next, and whether the people in the loop will actually use the new box instead of routing around it.
This is where strong technologies quietly die. Not in the lab in the integration layer. A platform that wins every standalone benchmark can still be useless if connecting it to an existing command-and-control system takes nine months of custom engineering, or if it demands that operators abandon a workflow they’ve trusted for a decade.
So when we look at a company, “what does the product do” is maybe half the analysis. The half that tells us more is: where does this sit inside an ecosystem that already exists, and how much pain does it cause to fit it in?
We’re really asking a few concrete things. What does the product depend on to function, and what would come to depend on it? How much of a deployment is configuration versus bespoke integration work that has to be redone for every customer? Can it run alongside legacy infrastructure that isn’t going anywhere? And, most importantly, can an operator adopt it without changing how they work?
None of this is a knock on the founder. It’s the opposite. The strongest teams treat integration as a design input from day one, not a problem to be solved after the product is built. The point isn’t to fear the question it’s to ask it early: at the architecture stage and during technical testing, what already exists in this environment, what are we working alongside, what is actually going to be replaced, and what do we have to connect to? A team that has those answers from the start builds a fundamentally different product than one that discovers them in the field.
Militaries Almost Never Operate In Greenfield
New tech has to coexist with old systems, entrenched procedures, weird communication architectures, and decision-makers who are not obligated to like your product. A technology that requires the organization to reshape itself around it is, in practice, a technology that won’t get deployed at scale, no matter how good the core capability is.
Which is why the most useful exercise in technical diligence is rarely the standalone demo. It’s watching the system operate next to other systems ideally messy, real ones. A drone shouldn’t just be judged on flight performance; judge it on whether it can talk to the C2 system the customer already runs. An AI platform shouldn’t be judged on model metrics alone; judge it on whether it can ingest real operational data, in the real format it arrives in, and feed a decision process that already exists. A sensor’s detection range matters less than whether what it detects can actually be shared across the wider architecture without a translation layer that nobody wants to build.
We’re Not Just Underwriting The Technology
There’s a phrase we keep coming back to internally: we’re not just underwriting the technology, we’re underwriting the company’s deployability. Is this team flexible enough to embed into a customer’s environment and actually ship? Or does every deal turn into a research project? Two companies with identical core tech can have completely different outcomes here, and it usually isn’t visible on the spec sheet.
This only gets more important from here. The sector is adding capability fast across autonomy, AI, robotics, sensing, and comms. More systems means more connection points, and more connection points means integration stops being an implementation detail and becomes the thing that determines whether value gets created at all.
My bet is that the companies generating the most value over the next few years won’t necessarily own the most advanced standalone technology. They’ll be the ones that slot cleanly into a larger operational picture and make everything around them work better.
For investors, the takeaway is simple to state and annoying to act on: you can’t run diligence on performance metrics and a spec sheet anymore. You have to get into how the thing deploys into the real world the integrations, the workflow fit, the team’s appetite for the unglamorous embedding work. Because in modern defense, a single system almost never wins or loses on its own. It wins or loses on how well it plays with everything it was never designed to meet.
