What Makes a Deftech Company Hard to Compete With

I have been thinking about what makes a deftech AI company genuinely hard to compete with over time. Not the advantages that look most obvious from a pitch deck, but the structural ones that deepen as a company matures and goes further into the environments it operates in. There is a purely theoretical version of this question, and a practical one that matters to founders deciding where to invest effort and to investors trying to understand what they are actually backing. This is an attempt at the practical version, aimed at companies in the early stages of that journey rather than those that have already arrived.

A Map of the Terrain

Before making any argument about which moats matter most, it is worth naming them. This is not an exhaustive list. The deftech AI landscape is still forming, and the full shape of competitive advantage in this sector is not yet settled. But the following is a reasonable map of the significant ones, at least as I have come to think about them.

The moats that exist here fall roughly into two groups. The first is relatively familiar: hardware and tactile barriers, where the physical cost and complexity of what you build makes it difficult to replicate quickly; private and classified data, where proprietary datasets, particularly those generated in operational or classified contexts, provide training and inference advantages that competitors cannot access; and sovereignty architecture, meaning the ability to deploy AI systems fully within a customer’s own infrastructure, air-gapped and on-premise, rather than via shared cloud environments.

The second group is less often discussed, and I think considerably more interesting: regulatory and accreditation infrastructure; knowledge and ontology; cleared human capital; operational data flywheels; long-cycle procurement relationships; and alliance-level positioning. The rest of this post is mostly about the second group.

The Ones Everyone Reaches for First

Hardware as a moat is real. Designing and manufacturing physical systems, whether sensors, autonomous platforms, or edge computing infrastructure, requires capital, engineering depth, and supply chain relationships that take years to build. The barrier is genuine. It is also binary: you either have the capability, or you do not, which makes it protective but slow to construct and expensive to maintain. At the far end of this moat sit companies like Anduril Industries, now valued at over $60 billion, building manufacturing infrastructure at a scale most startups will never approach. That is illustrative of what the hardware moat looks like at full maturity. It is less useful as a model for where to begin.

Private data is also real, and more interesting in defence than in commercial AI. The reason is classification. In commercial contexts, the data moat argument has been increasingly questioned, partly because large foundation models trained on public data can approximate capabilities that proprietary datasets were supposed to make exclusive. In defence, classification changes the equation. Data generated in operational contexts, particularly at higher classification levels, is structurally inaccessible to competitors regardless of their capital or engineering capability. You cannot train on data you cannot see. That asymmetry is more durable than most commercial data advantages.

Both of these moats are worth building toward. Neither is where the differentiation gets most interesting for a company in its early years.

The Ones Worth Getting After

The Compliance and Accreditation Moat

The regulatory environment across UK, NATO, and allied procurement is genuinely complex, slow to navigate, and expensive to achieve. That friction is also viewed from a certain angle as a competitive asset. Crucially, it is one that a startup can begin building from the moment it decides to. The timeline is long, but the starting point is available to anyone.

In the UK, the barriers include List X facility accreditation, a Ministry of Defence (‘MoD’) approval that allows a company to handle classified material on its own premises and takes years to obtain, and National Cyber Security Centre (‘NCSC’) Cyber Essentials Plus certification. At the NATO level, Standardisation Agreements (‘STANAGs’) and interoperability standards represent a different kind of compliance challenge, less about security accreditation and more about technical architecture. Systems designed from the ground up to meet NATO interoperability requirements are not just compliant. They are positioned across the whole alliance rather than a single nation. The UK’s Strategic Export Licensing regime performs a broadly similar function to International Traffic in Arms Regulations (‘ITAR’) in the United States, governing what technology can be shared and with whom. These export control frameworks are often experienced as constraints. They are simultaneously a map of which relationships are available to companies that navigate them correctly.

The more interesting angle, though, is what happens when you think at the alliance level rather than the national level. Five Eyes (‘FVEY’), the intelligence-sharing partnership among Australia, Canada, New Zealand, the United Kingdom, and the United States, is the clearest example. Achieve the relevant certification and accreditation within one member nation, and the pathway to the other four is materially shorter than it would be for a company starting from scratch. The compliance moat is not just national protection. It functions as a passporting mechanism across five allied defence markets.

AUKUS, the trilateral security partnership between Australia, the United Kingdom, and the United States, adds a further layer. Pillar II of the agreement, which covers advanced capabilities, including AI and autonomy, creates a defined technology-sharing framework that extends beyond intelligence sharing to active co-development of military systems. Companies whose architecture is designed to operate within that framework are not just compliant with one nation’s requirements. They are positioned within a trilateral procurement pipeline whose barriers to entry are high enough that first movers carry a structural advantage that is genuinely difficult to close.

The Global Combat Air Programme (‘GCAP’), the next-generation combat aircraft being developed jointly by the UK, Japan, and Italy, takes this logic into new territory. GCAP extends well beyond the Five Eyes and NATO axis. Japan’s inclusion creates a multi-jurisdiction compliance and interoperability challenge that no existing playbook fully solves. The regulatory environments across the UK, Japanese, and Italian defence procurement are meaningfully different from each other, and the AI and software systems that need to operate across all three will require a genuinely bespoke approach. A company that figures out how to build within that framework is not navigating existing routes. It is creating them, which is about as close to a structural first-mover position as a young company in this sector can find.

The Knowledge and Ontology Moat

This is the moat I find most underappreciated, partly because it is the least visible and partly because it is one of the few that begins compounding from a company’s very first customer deployment.

The most durable deftech software companies have not, in the end, built data platforms in the conventional sense. What they have built is a semantic layer: a structured map of how an organisation’s entities, relationships, and processes connect to and depend on each other. In practice, this means encoding not just data but also operational knowledge into the system’s architecture, so that the software reflects how the organisation actually works, not just how its data is organised. Palantir Technologies is the most documented example of what this looks like at scale, but the underlying logic is available to a much earlier-stage company working with its first serious customer. The architecture choice is made early. Its consequences compound for years.

The implication for switching costs is significant. Once a customer’s operational reality is built into your knowledge architecture, migration is not a procurement decision. It is closer to an institutional one. You are not replacing software. You are dismantling a structured representation of how the organisation understands itself and its operations, and rebuilding it from scratch in a different system. That is a meaningfully different kind of stickiness from a long-term contract or a hardware integration.

At the alliance level, this moat has an additional dimension. Systems that share intelligence across the Five Eyes or coordinate operations among AUKUS partners need a common way to describe the world. Entities, relationships, classification levels, operational concepts: all of these need to be legible across different national systems. The companies that build the connecting semantic layer between allied systems are not just delivering a product. They are becoming infrastructure in the way that communications standards are infrastructure. That position, once established, is exceptionally difficult to displace.

The Cleared Human Capital Moat

The least-technological moat is arguably also the hardest to replicate. It is not about what your systems are certified to do. It is about what your people know from having been genuinely inside the environments you are serving.

Engineers embedded in customer environments, working alongside operational teams on real problems over sustained periods, accumulate an understanding of how those organisations work that does not transfer cleanly into documentation or code. It lives in people. It is built on being present for decisions, understanding the pressures and constraints that drive them, and developing a feel for what the organisation actually needs rather than what it asks for. That kind of knowledge takes years to develop and cannot be acquired quickly, regardless of how much capital is available.

There is something worth noting about timing here. This moat is, in some ways, more naturally built at the startup stage than at scale. A small team can be genuinely embedded. A large organisation tends to service rather than embed. The founders and early employees who spend real time inside their first customer environments are building something that compounds in the background while everything else is being figured out. It is worth being deliberate about it early, because it becomes harder to retrofit later.

Companies that have built teams with that depth of operational embedment are not just better at building what their customers need. They are structurally harder to replace because the relationship and the insight are intertwined in ways that a competitor with better technology but shallower roots cannot easily overcome. A newer entrant can close a capability gap. Closing a trust and knowledge gap built over years of shared operational experience is a different kind of problem.

What Connects Them

The thread running through all three of these moats is that they are co-built with the customer and with the regulatory environment, rather than owned outright by the company.

A hardware asset is yours. A dataset, in principle, is yours. But an accreditation framework that embeds your architecture into how an alliance shares AI capability, a knowledge layer that encodes how a customer organisation understands its own operations, a team whose insight is woven into a programme of record: none of these is something you own in the conventional sense. They are things you have become part of. That co-construction is precisely what makes them sticky in ways that owned assets often are not, and they tend to compound over time rather than depreciate.

In a procurement environment that is increasingly coalition-based and alliance-driven, with frameworks like Five Eyes, AUKUS, and GCAP creating new multi-nation technology sharing arrangements that go well beyond traditional NATO structures, the companies that build at an alliance level rather than purely at a national level may have the most durable structural positions of all. Compliance, the ontology, and human capital reinforce each other when operating in that environment. Each makes the others harder to displace.

A Closing Thought

The companies I find most interesting in this space seem to have chosen one or two of these moats deliberately and gone very deep, rather than spreading effort across all of them. That may partly be a selection effect: the ones worth paying attention to are those that have survived long enough to develop a point of view on their own structural position.

What I notice, though, is that the moats most worth getting after are not the ones that require scale to begin building. The compliance journey starts when you decide it does. The ontology is shaped by your first serious deployment. The human capital moat begins with your earliest embedded relationships. None of them requires you to be a unicorn. They require you to be deliberate.

The choice of which moat to pursue is also, in some sense, a choice about what kind of company you are building toward. I am not sure whether founders always make that choice consciously at the start, or whether it tends to emerge from the work. I suspect it is usually the latter. Whether it should be the former is the question I keep coming back to.