What remains when an AI feature is copied?

A fictional medical technology company has spent a year developing an AI application that turns incoming technical complaints into a structured draft for professional review. A competitor now demonstrates a similar function. The founder can see the resemblance immediately. What is harder to assess is how much of the business has actually been copied: the screen, the output, the route to a customer, or the ability to keep the work useful after installation.

Evan Spiegel’s interview on Lenny’s Podcast prompted this distinction. He describes easily copied software features and Snap’s investment in relationships among users, creators and developers. His account concerns a consumer platform. It establishes no general law about healthcare AI or the disappearance of software advantages. [1]

For founders and investors in healthcare, I would examine what accumulates as the company does useful work. A feature can remain technically difficult to reproduce. It can also become easier to imitate while the surrounding capability improves. Neither possibility can be inferred from the appearance of a competing demonstration.

Define what the competitor would have to reproduce

David Teece’s 1986 strategy paper distinguishes an innovation from the complementary capabilities needed to commercialise it, including distribution and support. His theoretical argument makes the protection of the innovation and access to those capabilities consequential for capturing returns. The paper does not estimate the performance of present-day AI companies. [2]

Applied to the fictional complaint application, this gives me a practical starting point: describe one completed piece of work. Which information arrives, who judges the draft, what happens to an uncertain case, and where does the accepted result go? Then identify the parts supplied by the company, the customer and partners. A supplier can be crucial at one point and readily replaceable at another.

This exercise also protects against flattering descriptions of the business. A complicated installation is an expense. It becomes evidence of a valuable capability only if the company can explain what it has learned to do better and why a customer benefits. Difficulty alone provides no reason to expect durable demand.

Ask what the next deployment can inherit

In the example, the first customer may require substantial work on document formats, responsibilities and exception handling. Some of that effort will remain specific to its organisation. Other work might become a tested import component, a clearer specification of supported cases or a reusable way to show reviewers exactly which source supports a draft.

A 2026 Norwegian evaluation by Severinsen and colleagues followed a fracture-detection implementation through interviews, observations and documents. Teams reused and improved implementation documentation across sites. This qualitative study concerns early implementation within one health trust; it does not demonstrate durable supplier advantage or long-term effectiveness. [3]

The distinction I draw is between accumulating activity and accumulating capability. For the fictional company, an exception that leads to an explicit supported-case boundary can improve future decisions. An undocumented workaround that only the founder understands can make the next installation equally dependent on that founder. Both involve work; their implications for the company differ.

A useful record therefore connects a problem encountered, the change made and the circumstances in which it can be reused. It should also name what remains customer-specific. Learning from a deployment does not automatically authorise reusing the underlying information. Patient data, confidential complaints and unpublished research require their own agreed boundaries. An appropriately constructed artificial example may capture a recurring problem without transferring a customer’s original material.

Customer access has to lead somewhere useful

In this setting, I would examine access through the decision it enables. A conversation with a clinician, a specialist conference or a distribution partner can introduce a real problem and the people responsible for it. The company still needs to establish whether that problem is sufficiently important, whether its application fits, and whether a funded implementation is possible.

For a physician-founder, this makes public explanation and product work closely related. A substantive talk can surface objections that a demonstration never reveals. Its commercial value depends on what follows: a relevant conversation, a better specified use case or an informed decision to decline an unsuitable opportunity. Audience size alone cannot establish that value.

The same scrutiny applies to partnerships. A partner may provide an established route into hospitals while retaining the customer relationship and deciding which competing applications to offer. That arrangement can be useful. The founder should be able to name what the company continues to contribute if the partner adds an alternative. A list of partner logos leaves this dependency unexplained.

Accumulated experience can contain unresolved failures

Naicker and colleagues’ 2026 study used 43 interviews across the implementation of radiology AI at one Australian hospital. Participants described persistent integration and communication problems. This qualitative account includes staffing and organisational changes; it cannot isolate causal effects or establish a commercial result. [4]

For the fictional company, this is a reason to examine what became of its learning. More installations could produce a larger collection of unresolved support cases. A familiar brand could coexist with cumbersome work. An established relationship could continue because replacing the application is difficult. Each can sustain current revenue for a while without demonstrating that the next customer receives a better product.

I would therefore test the company's explanation against a deliberately uncomfortable assumption: a capable competitor can now offer a comparable core function. Which customer benefit remains, which evidence supports it, and what would show that the claimed advantage has weakened? The answer should name something more inspectable than experience, trust or an ecosystem.

Look for reuse without hiding its cost

For the next few comparable opportunities, record what the team expects to reuse and what must be developed afresh. Keep the intended task, quality requirements and boundaries visible. During the work, record customer effort alongside supplier effort, including the founder’s time, unsuccessful attempts and opportunities abandoned after substantial preparation. A smooth final installation can otherwise conceal the effort required to reach it.

Fewer hours on a later deployment would be an observation worth investigating. The customer might simply have cleaner information or a narrower requirement. Establish which component or working method actually transferred before attributing the difference to organisational learning. This proposed comparison supports management judgement. Its ability to predict growth or profitability has not been validated.

Also examine whether the accumulated capability still answers a problem customers have. An improvement in a widely available model might eliminate a previously difficult step. A changed workflow might remove demand for the application altogether. A company can retain technically impressive knowledge whose commercial relevance has diminished. Durability requires reconsidering what deserves further investment.

For me, the useful founder question is what today’s work leaves available tomorrow: a product that handles a relevant class of cases better, evidence that helps the next responsible buyer judge it, or a team able to deliver without repeating every discovery. These are propositions to substantiate. They give a more concrete basis for the next investment of time and capital than counting how many features competitors have copied.