Founders building products on top of foundation models spend considerable time thinking about the risk that the models fail — hallucinate too frequently, become unavailable, or prove incapable of the task. This risk is real and worth designing for. It is not, however, the risk that is most likely to kill an AI product. The more common and less discussed risk runs in the opposite direction: the model improves, and the capability your product was built to provide becomes a default behavior of the model itself. The gap you built a business around closes, not because the technology failed, but because the technology succeeded.
Foundation model risk, properly understood, is not the risk of model failure. It is the risk of model improvement outpacing your differentiation strategy. A product that solves a problem by wrapping a current model capability in better prompting, a cleaner interface, or a more reliable pipeline is exposed to the risk that the next model version does those things natively. The barrier to entry in many AI product categories is currently created by limitations in the base model — and those limitations are being actively worked on by organizations with more resources than most startups. Building a business on top of those limitations is building on a foundation that its architects intend to remove.
What makes differentiation vulnerable to model improvement
Not all differentiation built on foundation models is equally exposed to improvement risk. The exposure depends on what the differentiation is built on. Differentiation that is built on the model’s current capability ceiling — on doing something the model cannot currently do well without significant scaffolding — is exposed whenever the model’s ceiling rises. Differentiation that is built on domain specificity, workflow integration, or proprietary data is not directly exposed, because model improvement does not eliminate the domain knowledge, the workflow embedding, or the data.
The most vulnerable form of differentiation is prompt-based capability. A product that achieves its core value by prompting the model in a way that produces outputs the model would not produce with a naive prompt is differentiated by its prompting approach. That approach is vulnerable on two fronts: other developers can reverse-engineer it by observing outputs, and model improvements can make it unnecessary by producing equivalent outputs with simpler prompts. Prompt engineering as a moat has a shelf life that is inversely related to the rate of model improvement, and the rate of model improvement has not slowed.
The second vulnerable form is output quality on specific tasks. Many AI products differentiate on the quality of their outputs for a specific task type: summarization, code generation, document extraction, customer support response quality. If the differentiation is “we produce better outputs than a raw API call for this task,” the differentiation is exposed to any model release that makes the raw API call better at that task. Products in this category are running a constant race in which the race conditions are set by model labs, not by the product team.
The less vulnerable forms of differentiation are those that are not reducible to model capability. A product that has accumulated a large proprietary dataset that improves model outputs for a specific domain has differentiation that model improvement does not erase — better base models trained on that dataset still require the dataset. A product deeply embedded in a customer’s operational workflow has differentiation built on switching cost that model improvement does not reduce. A product that coordinates between multiple specialized models in a way that produces system-level behavior has differentiation built on architecture rather than on any single model’s output quality.
How model improvement compounds into product displacement
The displacement pattern for AI products exposed to foundation model improvement is gradual and then sudden. It is gradual because model releases improve incrementally in most dimensions, and the gap between a product’s differentiated output and the base model’s output closes slowly enough that it is not alarming at any single release. It becomes sudden when two conditions coincide: the model reaches the capability threshold where the gap is small enough to be irrelevant for most users, and a new entrant (or the model provider themselves) releases an interface layer that makes the base capability accessible without the product’s scaffolding.
The model provider displacement scenario deserves specific attention. Foundation model providers have strong incentives to move up the stack and capture the value that is currently being captured by application-layer products built on their APIs. When a model provider releases a native interface for a task category — customer support, document summarization, code review — every product in that category built primarily on capability rather than domain specificity or workflow integration faces a direct competitive threat from its own infrastructure provider. This is not a hypothetical. It has already occurred in several AI product categories and the pattern will continue as providers identify where application-layer value is being created above their base offerings.
How to identify your exposure and build around it
The goal is not to avoid building on foundation models — that is not realistic advice for most AI product categories. The goal is to build in a way that accumulates differentiation that does not erode when the model improves. These steps address that directly.
-
Map your differentiation into three categories: model-dependent, workflow-dependent, and data-dependent. Model-dependent differentiation is what your product can do because of how it uses the current model. Workflow-dependent differentiation is what your product can do because of where it sits in the customer’s process. Data-dependent differentiation is what your product can do because of information it has accumulated that the model alone does not have. The second and third categories are durable. The first is exposed.
-
For each model-dependent advantage, ask: would a model two generations better eliminate this? If yes, treat that advantage as a temporary margin, not a moat. Plan explicitly for a product strategy that does not depend on that advantage being permanent. This is not pessimism — it is the correct time horizon for a feature built on a limitation that the underlying technology is actively trying to close.
-
Build workflow integration before capability differentiation. The sequence matters. A product that is embedded in a customer’s workflow before a better model makes its capability advantage irrelevant has switching cost protection when the model improves. A product that achieves high capability differentiation without workflow embedding has no protection. Make the workflow embedding the first priority, not the refinement of AI output quality.
-
Accumulate proprietary data from production use. Every customer interaction with your product is an opportunity to collect domain-specific data that improves the model’s outputs for that customer or customer segment. Structured feedback, correction data, usage patterns, domain-specific examples — these compound into a dataset that makes your model integration better than a fresh API call. The dataset is yours. The model improvement benefits you and the market equally. The dataset benefits only you.
-
Define a response strategy for each foundation model provider’s product roadmap. Identify the three capabilities on the base model’s announced or likely roadmap that, if released natively, would most directly threaten your current differentiation. For each one, define what your product would need to have accumulated by then — in workflow embedding, data, or customer relationships — to retain the customer relationship through the transition. This is contingency planning, not paranoia.
What durable AI products are built on
The AI products that will retain their market position through multiple generations of foundation model improvement are not the ones with the best prompting or the cleanest UI on the current model. They are the ones that have used the current model’s capabilities to establish a position — in data, in workflow, in customer relationships — that does not depend on the model staying where it is.
The model is going to improve. The labs have announced it, the investment is behind it, and the trajectory is consistent enough to treat as a planning input rather than a speculation. The question for every founder building on foundation models is not whether the improvement will happen, but whether the business they are building will be worth more or less when it does. Products built on limitations will be worth less. Products built on domain knowledge, operational workflow, and accumulated data will be worth more — because a better model, applied to a richer dataset in a deeply embedded workflow, produces better outcomes than a better model applied to nothing. The model improvement is the rising tide. The question is whether your product is a boat or a sandcastle.
