Jeff McMillan opens his recent TechRadar essay with a brutal proposition: your AI application is not that special.
The models are shared. The cost of building is collapsing. Good software can be copied faster than most founders can build a company around it. McMillan expects infrastructure to consolidate and application companies to survive only when they control some combination of proprietary data, distribution, and workflow integration.
The diagnosis is directionally right.
But the usual moat checklist misses the mechanism that makes those assets valuable.
Data can sit unused. Distribution can buy trials that never become habits. Integration can create migration pain without making the product better. None of them compounds automatically.
The defensible unit is not the product, the model, or even the dataset.
It is the operating loop that turns real work into verified outcomes, verified outcomes into system improvement, and system improvement into more trusted work.
Application Abundance Is Real
The exact scale of the AI-company boom is difficult to establish. McMillan cites more than 70,000 AI companies worldwide, but the article does not identify the underlying dataset. The number is better treated as scene-setting than as a measured market base.
The direction, however, is well supported.
A 2026 NBER working paper studied more than 100,000 GitHub developers across successive generations of AI coding tools. The researchers found that autonomous agents were associated with a 180% increase in commits, but the effect narrowed to 50% for projects and 30% for releases. Across four major application marketplaces, they found more new applications without an increase in aggregate usage.
AI is increasing the supply of software faster than it is increasing demand for any particular product.
That weakens feature-level advantage. A capable interface, a clever prompt chain, or temporary access to a better model can still produce value. It is simply easier for a competitor, an incumbent, or the customer itself to reproduce.
This does not mean the application layer has no future. It means a snapshot comparison of product quality tells us less about future advantage than it used to.
The better question is not How good is the product today?
It is What becomes harder to reproduce after the product has been used for a year?
Moats Are Systems, Not Ingredients
This problem predates AI.
In his classic 1986 paper on profiting from technological innovation, David Teece argued that inventors often fail to capture the value they create when imitation is easy. The returns instead flow to whoever controls the complementary assets needed to commercialize the innovation: manufacturing, distribution, service, specialized capabilities, or access to customers.
AI changes the speed of imitation. It does not repeal that logic.
Models and generated code make the technical invention easier to reproduce. That increases the importance of complementary assets around it. McMillan's data, distribution, and integration are modern versions of Teece's framework.
But they are often discussed as possessions:
- We have proprietary data.
- We have an installed base.
- We are embedded in the workflow.
Possession is not enough. Each asset has to participate in a learning system.
Static data is an archive. Distribution without retention is rented attention. Integration that only makes departure expensive is a switching tax.
A moat appears when those assets reinforce one another through use.
Proprietary Data Matters Only When It Closes the Loop
The phrase “proprietary data” carries more confidence than precision.
A company may own millions of documents and still have no defensible learning advantage. The records may be stale, inconsistent, legally restricted, weakly connected to outcomes, or irrelevant to the decisions the AI system must make.
The valuable data is usually generated inside the operation:
- what the system recommended,
- what action a person accepted or rejected,
- what exception required escalation,
- what happened after the decision,
- and whether the outcome was actually good.
That is not merely more context for a prompt. It is evidence about performance.
The published study “Generative AI at Work” shows why this distinction matters. Researchers studied 5,172 customer-support agents using an assistant trained on patterns from prior support interactions. Access to the system increased issues resolved per hour by 15% on average, with the largest gains among less-experienced workers. The system's value came partly from making previously tacit practices from stronger workers available during real conversations.
The defensible asset was not a generic chatbot. It was the connection between domain history, live workflow, observed success, and assistance at the moment of work.
Even then, data becomes a moat only if the company can legally use it, reliably evaluate it, and convert it into product changes. A warehouse full of conversations is not a learning loop. A stream of accepted outcomes linked to system behavior can become one.
Distribution Starts the Loop; It Does Not Finish It
An installed base gives an incumbent a serious advantage. It can place a new capability in front of customers without acquiring every user from zero.
But distribution only creates exposure. It does not guarantee that the product earns more work.
In a conventional launch model, distribution is a funnel:
attention, trial, conversion, renewal.
In a compounding AI product, distribution is also an input to learning. More appropriate use produces more edge cases, more corrections, more outcome evidence, and more chances to improve the system. Improvement earns trust. Trust expands the volume and consequence of work the customer is willing to delegate.
The loop is:
real work → observed outcome → evaluation → improvement → trust → more real work
Distribution is powerful because it can accelerate that cycle, not because an audience is permanently owned.
This also explains why reach alone is a fragile moat. A competitor can buy attention. A platform can change its ranking. A model provider can bundle a similar feature. What is harder to copy is the accumulated operational learning produced after thousands of customers have trusted the system with the right kind of work.
Integration Should Create Intelligence, Not Hostages
Workflow integration is often described as defensible because removal is painful.
That is true, but incomplete.
The Federal Trade Commission's study of partnerships between cloud providers and AI developers warns that contractual and technical arrangements can increase switching costs and restrict the ability to use alternative providers. Lock-in can protect revenue. It can also attract customer resistance, regulatory attention, and a determined architecture program designed to remove the dependency.
The stronger form of integration is productive rather than coercive.
It gives the system the context required to act, exposes whether the action worked, preserves an audit trail, and returns the result to the systems where people continue their work. Removing the product is costly because the customer would lose accumulated performance and assurance, not merely because data export is unpleasant.
This distinction matters for product strategy:
- Bad switching cost: leaving requires a migration project.
- Durable replacement cost: a replacement must recreate the learning, controls, trust, and operating performance built over time.
The first holds a customer in place.
The second gives the customer a reason to stay.
Your Customer Is a Competitor—and a Test of Your Learning Rate
McMillan makes one of his strongest points when he says the AI application startup also competes with its buyer.
The enterprise already owns its workflows, customer access, policies, and much of the relevant data. As coding and orchestration become easier, an internal team can reproduce more of what once required a software vendor.
But “we can build a version in a quarter” is not the end of the build-versus-buy decision.
The real comparison begins after launch:
- Who will evaluate the system across changing models and edge cases?
- Who will maintain the integrations, permissions, and auditability?
- Who will detect regressions and incidents?
- Who can learn across deployments without exposing one customer's sensitive data to another?
- Who can improve the workflow faster than the underlying capability commoditizes?
The customer has local context. A good vendor has a chance to build a higher learning rate across many contexts.
That does not require pooling confidential records into one indiscriminate dataset. The transferable advantage may come from evaluation methods, failure taxonomies, policy patterns, workflow design, model routing, anonymized benchmarks, or operational knowledge about where humans must remain in control.
The vendor wins when it can turn experience across the market into better performance for each customer while preserving the boundaries each customer requires.
If it cannot, the customer may reasonably conclude that ownership is more valuable than the subscription.
The Operating-Loop Test
Before calling an AI product defensible, I would ask five questions:
- Which verified outcome becomes visible because the product sits inside the workflow? A click or generated answer is activity, not an outcome.
- Does the company have the rights and controls to learn from that evidence? Sensitive data that cannot be used is not a practical learning asset.
- What changes because of the feedback? The answer might be retrieval, tools, routing, policies, evaluation, interface design, or human escalation—not necessarily model training.
- How quickly does the loop run? Quarterly anecdotes will lose to a competitor that can detect and correct failures every week.
- What would a replacement have to recreate? If the answer is only the interface and prompt, there is no meaningful moat yet.
The test is deliberately operational. It moves the conversation away from pitch-deck nouns and toward a measurable rate of learning.
The Product Does Not Have to Be Special
William Nordhaus estimated that innovators captured only a small fraction of the social returns from U.S. technological progress between 1948 and 2001. His result is a macroeconomic estimate, not a forecast that every AI vendor will retain exactly 2% of the value it creates. But it is a useful warning: creating value and capturing value are different problems.
AI will create extraordinary value even if most AI products disappear, consolidate, or pass much of their benefit to customers.
The companies that retain a meaningful share will not do so because their first version looked uniquely intelligent. They will do it because every completed task improved the system that delivered the next one.
Your AI product does not need to remain special.
It needs to become harder to replace.
The feature is what the customer sees.
The operating loop is what the competitor cannot download.
Sources
- Jeff McMillan's TechRadar essay provides the immediate argument about AI-market consolidation, application abundance, and data, distribution, and integration as differentiators.
- Mert Demirer, Leon Musolff, and Liyuan Yang's NBER working paper “Writing Code vs. Shipping Code” measures how AI coding tools affect commits, projects, releases, and application-marketplace activity.
- David Teece's “Profiting from Technological Innovation” supplies the foundational framework for imitation, appropriability, and complementary assets.
- Erik Brynjolfsson, Danielle Li, and Lindsey Raymond's open-access Quarterly Journal of Economics paper “Generative AI at Work” studies an AI assistant embedded in customer-support work.
- The Federal Trade Commission's AI partnerships report documents contractual and technical switching-cost concerns in cloud and model-provider relationships.
- William Nordhaus's NBER paper “Schumpeterian Profits in the American Economy” estimates how the social returns from technological change were divided between producers and consumers from 1948 to 2001.