The shift from buying programs to buying capabilities could reshape procurement — and it puts a premium on an unglamorous layer of infrastructure that sits between innovation and deployment.

For decades, buying defense technology followed a predictable sequence: define a requirement, build a program around it, pick a contractor, develop the system, test it, certify it, produce it, field it. The whole thing could take years, and for the biggest systems, decades.

That made sense when the technologies that mattered most were large, tightly integrated platforms meant to stay relevant for a generation. A carrier or a fighter airframe is supposed to last thirty years, so it’s worth spending a decade getting it right.

It makes far less sense when the relevant technology cycle is measured in months. Autonomy keeps improving. Sensors keep getting cheaper. AI models turn over, electronic warfare environments shift, new drone architectures show up, manufacturing techniques advance, and a few weeks of combat can rewrite a requirement that took years to write. A system designed around today’s threat can meet a different version of that threat by the time it reaches the field.

The Pentagon knows this. Recent acquisition reforms lean hard on mission outcomes, faster fielding, modular architectures, and the ability to upgrade a system repeatedly instead of waiting years for the next redesign. Senior acquisition officials have said plainly that both software and critical hardware need to change far more continuously than the old model allowed.

So something bigger than procedural reform may be underway. Defense is starting to move from buying programs to buying capabilities, and once it does, parts of the market start to behave a lot like software.

From programs to capabilities

Strip it down and the old model reads: requirements, program, development, testing, certification, production, deployment. The emerging one reads differently: a problem, a search for what already exists, validation, purchase, deployment, feedback, upgrade, scale.

Pieces of that second model are already visible. The Defense Innovation Unit’s Commercial Solutions Opening process lets the government describe a problem and ask what companies already have, rather than specifying a new product from scratch. DIU says it can award prototype agreements in 60 to 90 days, and a prototype that works can move into production without another full competition.

That sounds like a scheduling win. It’s actually a change in the opening question, moving from “what should we design?” to “who already has the best answer?” That’s much closer to how commercial technology gets bought. Companies don’t design a new database for every application or stand up new cloud infrastructure for every launch; they evaluate what’s on the market and pick. Increasingly, defense buyers can do the same with certain sensors, autonomy stacks, radios, drones, and software platforms: find what exists, test it, buy it, field it, and when something better shows up, upgrade or replace it.

The platform doesn’t have to be the product

This matters more once systems become modular. Historically, winning a major platform locked in your suppliers and your technology choices for years, because swapping an important component could mean redesigning or recertifying big parts of the system. Modular open architectures exist specifically to break that lock, and current U.S. reform explicitly calls for competition at the module level: systems where components or software can be swapped without rebuilding the whole platform.

The software comparison gets sharp here. Modern software isn’t one monolith; it’s interchangeable layers — cloud, database, models, payments, security, analytics — and you can replace one without touching the rest. Picture that across more defense systems. The best sensor takes the sensor layer, the best autonomy stack takes the autonomy layer, the best countermeasure wins against a particular threat, and none of those winners is guaranteed to hold its slot forever. Competition shifts from the platform down to the component. For emerging companies, that’s a far more open market than one decided by which prime wins the airframe.

Deployment stops being the finish line

Software also normalized a second idea: the product is never done. Shipping is the start of the loop, not the end of it — deploy, watch how it behaves, update, improve, deploy again.

Defense increasingly needs to work this way too. The Pentagon’s Software Fast Track initiative was set up to overhaul how secure software gets tested and authorized, with new approaches to verification and risk meant to speed adoption. The logic is spreading past pure software: reform language now calls for adaptable testing, faster certification, and repeated updates to critical hardware, with the explicit goal of replacing multi-year redesign cycles with architectures that adapt as threats do. The Department’s 2026 AI strategy makes the direction obvious. Its Swarm Forge initiative is built to repeatedly discover, test, and scale AI-enabled capabilities alongside operational units — which is not program acquisition. It’s a market.

A test case: the counter-drone marketplace

You don’t have to imagine this shift anymore. In 2026 the Pentagon started building the marketplace itself.

Joint Interagency Task Force 401, the body stood up to spread counter-drone capability across the U.S. military and other agencies, awarded a four-year-old software startup called Kaizen roughly $15 million in early May to prototype a “Counter-Unmanned Aircraft Systems Marketplace”: a screened, online catalogue where troops, law enforcement, and select allied militaries can search counter-drone systems, compare price and capability, and buy. Access is tiered, filtering listings by export control and classification. Vendors post their own technical specs, repair details, and compliance information, and task force administrators approve what goes up. Anduril, DroneShield, AeroVironment, and SMARTSHOOTER were among the first companies listing products; Australia, Poland, South Korea, the U.K., and Romania were among the first foreign buyers.

Read that back against the model this piece opened with. Discover what exists, compare it, buy it, upgrade when something better appears — that isn’t a metaphor here, it’s the product spec. Army Secretary Dan Driscoll has pitched the marketplace explicitly as a commercial-style answer to the purchasing bureaucracy that has historically slowed delivery. And it was built like software: Kaizen says it went from a blank slate to a live system in under nine weeks, assembled on top of two existing products — a library of compliance building blocks and an AI tool to configure them — plus an agent meant to scan the catalogue and recommend a capability mix across the kill chain.

The reason any of this exists is grim, which is precisely why “what actually works” isn’t an academic question. The catalogue was built against the backdrop of the war with Iran, where the cost-mass imbalance is brutal: expensive, hard-to-build U.S. interceptors thrown against cheap Iranian drones. In the war’s first days, an Iranian drone killed six American soldiers in Kuwait, and survivors later disputed the Pentagon’s claim that they had been adequately protected. Speed is not a convenience in that context. Neither is being right.

And that is exactly where the marketplace meets the limit of its own premise. It is very good at aggregating supply and collapsing the time from problem to purchase order. It cannot, by itself, tell a buyer that a listed system will hold up under jamming, in the wrong weather, against next month’s drone. As of August the platform was live but deliberately slow-rolled — a handful of orders, still largely in testing with administrators, with around $21 million in purchases logged. The catalogue is real. The trust layer underneath it is still being built.

But a missile isn’t SaaS

Here the analogy runs out. You can push a SaaS release to 5% of users and roll it back when something breaks. You cannot A/B test an interceptor against an incoming raid. Physical defense technology carries demands that most software never faces at the same stakes — safety, reliability, performance across brutal environments, resilience under jamming, integration, supply-chain security, manufacturability, survivability in the field — and the cost of getting it wrong is measured in lives and battles, not churn.

That produces a paradox worth sitting with: the easier defense technology becomes to discover and buy, the harder the validation problem gets. Drop the procurement barriers and a program office may suddenly face twenty autonomy platforms, thirty counter-drone systems, and a dozen AI-enabled sensors all claiming the same mission. A catalogue can tell you what’s for sale. It can’t tell you what actually works.

The missing layer is trust

That’s why faster buying won’t kill technical diligence; it raises the premium on it. Before anyone can buy at something like commercial speed, someone still has to answer the hard questions. Does it perform as advertised, and under what conditions? What happens when GPS drops or the spectrum gets contested? Will it integrate with what’s already fielded? Does the performance survive outside the vendor’s own demo? Can the company actually manufacture these at the scale a real deployment needs, from tens to thousands? Is the core technology genuinely differentiated, or is a slick demonstration hiding dependencies that fall apart under operational load?

Those questions are the trust layer between innovation and procurement, and that layer is starting to look like infrastructure in its own right: technical diligence, testing, certification, integration, procurement rails, and continuous validation once systems are fielded. At UAX we’ve spent a lot of time on technical diligence, and lately on testing infrastructure, and the more we look the less these seem like separate problems. They read like parts of the same emerging architecture.

Software became easy to buy because an enormous trust infrastructure grew up around it: cloud standards, security frameworks, APIs, benchmarks, reviews, monitoring, continuous deployment. Defense will need its own version. Not a copy, and far more rigorous, but pointed at the same goal — making it possible to evaluate, trust, and adopt technology faster.

The real revolution

The future here won’t quite look like an app store, even now that a literal catalogue exists. A screened, tiered marketplace for counter-drone systems is a long way from one-click consumer software, and aircraft, missiles, and major autonomous platforms aren’t going to become monthly subscriptions. But the mechanics of the market can still change a great deal: from bespoke development toward adapting what already exists, from monolithic systems toward modular ones, from one-time buys toward continuous upgrades, from decade-long cycles toward repeated rounds of discovery, testing, and scaling, and from a handful of closed programs toward a genuinely competitive ecosystem.

That’s a large opportunity for defense startups. It also relocates the bottleneck. The hard part may no longer be building better defense technology, or even buying it. It may be building the trust infrastructure that lets governments evaluate and field technology as fast as the technology itself now moves. Because if defense really does start buying more like software, the most valuable thing to have is a credible answer to one question: what actually works.