AI features and AI-native products are not the same thing
"Thin wrapper" is a bad criticism made on the wrong axis
Thesis
The wrapper insult has been the laziest argument in software for three years, and the people making it are pointing at the wrong thing. They point at code volume: how little of this product is yours, how much is an API call, how quickly someone could rebuild it.
None of that predicts anything. Plenty of durable businesses are thin over something they do not own, and plenty of technically elaborate products are worth nothing.
The question is not how thin the product is. It is whether anything accumulates that the model provider does not have. State, correction data, permissions, an installed workflow, a relationship with a system of record. If something compounds there, thinness is irrelevant. If nothing does, then the product is one model release away from being a feature of something else, and the amount of code in it makes no difference to that.
That reframing also settles the feature-versus-native question, which is usually asked as a status contest and is actually an architecture decision with different economics on each side.
Context
Right now three distinguishable things get sold with the same vocabulary.
An AI feature adds a capability to a product whose job already existed. Summarise this thread. Draft a reply. Explain this chart. The information architecture is unchanged. The feature is additive and, importantly, removable: take it out and you still have a product.
An AI-native product reorganises the job around an operation that only became cheap recently. Remove the model and there is nothing left, because the workflow it implements was not previously possible or worth doing.
An AI-shaped interface over someone else's capability is a different animal from both. It is a good prompt, a nice input surface and a rendered output. It may be genuinely useful and it may sell well, and it has no store of value in it.
Founders routinely pitch the second and build the third, then defend the mismatch by arguing about the first. Investors return the confusion by asking whether a product is "really AI-native", which is not a question about anything measurable.
Research
The relevant literature here is not about AI at all. It is forty years of work on who captures the value created by an innovation, and it answers this question more cleanly than anything written about models.
Teece, 1986, "Profiting from Technological Innovation". The central finding is that innovators frequently fail to capture the returns from their own innovations, and that the outcome turns on two things: whether the innovation is appropriable, and who controls the complementary assets needed to deliver it. When imitation is easy and complementary assets are held elsewhere, the returns flow to whoever holds those assets, not to whoever had the idea.
Applied here: the model is not your innovation and it is not appropriable by you. So the question Teece forces is which complementary assets you hold. Distribution into a specific buyer. Access to a system of record. A data set nobody else can assemble. If the answer is none, his framework predicts your margin goes to the layer below.
Christensen, Verlinden and Westerman on interdependence and modularity, and Baldwin and Clark's Design Rules before it. As an architecture modularises and its interfaces standardise, performance in that layer stops being the basis of competition and profits migrate to adjacent layers that are still not good enough. Model access has modularised extraordinarily fast: a standard interface, several interchangeable providers, falling prices. The prediction that follows is not that AI products are worthless. It is that value is currently migrating out of the model layer and into whatever remains hard, which is integration, reliability, workflow and trust.
Sutton's "bitter lesson", 2019. His argument is that general methods which scale with compute have repeatedly beaten hand-crafted domain knowledge, and that the field keeps relearning it. Read as a risk model for product builders it is blunt: scaffolding built to compensate for a model's current weakness is scaffolding built to be absorbed. Every elaborate prompt chain that patches a reasoning gap is a bet against the next release.
That gives a usable test. Ask whether your product's core work would become unnecessary if the model got substantially better. If yes, you are holding a temporary position. If your work is about state, permissions, accountability or proprietary data, model improvement makes you better rather than redundant.
Iansiti and Lakhani, 2020, on data loops as an operating model. Their argument is that the durable advantage in AI-centred firms sits in the loop, where usage produces data that improves the product that attracts more usage. The important qualifier, often dropped: the loop has to close inside your product. Usage that improves a vendor's model and leaves nothing behind in yours is not a loop. It is a subsidy.
Argument
Substitutability, not thinness, is the axis.
Three questions, in order of how much they tell you.
What accumulates here that a competitor starting today would not have? Not "what have we built" but what grows. Correction data. Configuration a customer spent a week on. A history that becomes context. Integration credentials and the permission relationships around them.
What breaks if the model changes? If a better model makes your product substantially better, you are positioned with the current. If it makes half your codebase pointless, you are positioned against it.
Where does the output get used, and do you own that place? This is the one people skip. A product that returns text into a chat window has handed the last mile away. A product that puts the output into the artifact the user is actually accountable for is much harder to displace, because displacing it means replacing the artifact.
The three things that actually compound, none of which is model access.
The workflow surface. Where the work happens, where it is reviewed, where it is corrected, where it is approved. This is unglamorous and it is where switching costs live. Users do not leave the place their process is encoded, even for better output.
The correction loop. Every time a user fixes your product's output, that is a labelled example, and it is worth something only if you keep it and use it. Most products throw this away. It is the single most underexploited asset in the current generation, and it is entirely available to a small team.
The permission and integration surface. Access to the systems where the truth lives. Hard to obtain, slow to replicate, and it gets harder to displace over time rather than easier. It is also the least fashionable thing to build and the reason a competitor with a better demo cannot take your customer.
Feature or native is an architecture decision, not a ranking.
An AI feature inside an existing product is often the better business. You already have the workflow surface, the data and the distribution, which are exactly the complementary assets Teece says determine capture. The feature borrows all three. That is a strong position and nobody should apologise for it.
An AI-native product has to build all three from nothing, which is why most fail, and it is only the right choice when the newly cheap operation makes a job possible that was previously not worth doing at all. Not faster. Possible.
The failure mode is mismatch. A native narrative with feature architecture is a company that has told investors it is reorganising a workflow while shipping something removable. A feature narrative with native architecture is a company that has built genuine infrastructure and is describing it as an add-on, which is rarer and mostly a pricing mistake.
The honest test for native, which is architectural rather than rhetorical.
Does the product's information architecture differ from what it would be without a model? If your navigation, objects and states are the same as the pre-AI version of this product with a generate button added, it is a feature. If the objects themselves are different, because the model made a new unit of work coherent, it is native. That test is checkable by looking at a screen, which is more than can be said for most uses of the word.
Examples
Summarisation in an email client. A feature, correctly. The client owns the inbox, the identity, the workflow and the distribution. The model adds capability to a job that already existed, and if the model improves the feature improves. Nobody should call this AI-native and nobody should need to.
A support product that resolves tickets and learns from the resolutions. Native, if the loop closes internally. Every agent correction becomes retrieval context, response quality rises for that customer specifically, and the value is in their history rather than in the model. The same product without retained corrections is a wrapper with good marketing.
A "chat with your documents" product. This is the canonical wrapper and the reason the critique exists, but the diagnosis is more specific than thinness. It fails because nothing accumulates: no state, no corrections retained, no place the output has to live, and the capability is being absorbed into the model vendors' own products. The code volume was never the issue.
A creator discovery product. Native in principle, since ranking creators by pre-virality signal is not a job anyone did manually. Its defensibility rests entirely on data access, not on the model, and if the data comes from a platform API that can revoke or price it, the complementary asset belongs to the platform. I know this one from the inside and I did not resolve the data question before writing code.
Counterargument
"Distribution beats architecture, and the platform-risk argument has been wrong every time it has been made."
The strong form of this is hard to dismiss. Companies built entirely on AWS became enormous. Companies built entirely on the iOS App Store became enormous. In both cases sophisticated people warned about dependence on a platform that could absorb them, and in most cases the platform did not, because the platform's incentives ran toward a healthy ecosystem rather than toward eating each application. Meanwhile the products that won were mostly the ones that reached customers first, not the ones with the most defensible architecture.
There is a sharper version: defensibility is a question you get to have after you have demand. Most products die from nobody wanting them, not from being copied. Spending your first year building a correction loop and integration surface for a product nobody has validated is a sophisticated way to fail. And "AI-native" is frequently a fundraising word rather than a technical one, which means arguing about the definition is participating in someone else's marketing.
Where this is right. Sequence matters more than my argument implies. If you have no users, defensibility is theoretical, and thin-and-distributed beats deep-and-unwanted every time. I would take a wrapper with a thousand paying customers over an architecturally elegant product with none, without pausing.
Where I think it is wrong. The AWS and iOS analogies hold for platforms whose business is selling capacity to applications. Model providers ship consumer and business applications of their own, on top of the capability they sell you, which is a different structure. The features absorbed into those applications over the last two years were mostly single-step text operations, which is exactly the category the wrapper critique describes.
And the two positions are not actually in conflict on timing. Nothing in the three compounding assets requires a year. Retaining corrections is a database table. Owning where the output lands is a design decision. You can ship thin and still choose an architecture where usage leaves something behind, and the cost of that choice at the start is close to zero. The cost of retrofitting it after two years of throwing the data away is not.
Practical implications
Write down what accumulates. One page. If the list is empty, you have a distribution business, which is fine, but you should know that is what you are running.
Retain every correction from day one. Store the original output, the user's fix and the context. You will not know what it is worth for a year and you cannot recover it retroactively.
Own where the output lands. Push results into the artifact the user is accountable for rather than returning them to a chat pane.
Ask what a much better model does to you. Score each core component: improved, unaffected, or obsoleted. If the obsoleted column holds your differentiation, change position now rather than after the next release.
Pick a side deliberately. Feature means you already hold the complementary assets and should exploit them hard. Native means you are building them from zero and should say so internally, because it changes the timeline and the funding requirement.
Check your information architecture against the pre-AI version. If it is the same product with a generate button, stop calling it native.
Resolve data access before writing code if your thesis depends on data you do not own. A rate limit or a permissions review can end the product, and finding that out after the prototype is a self-inflicted wound.
My perspective
Opinion, and drawn from my own record rather than the sources above.
TapQR's public positioning names three pillars: AI fraud detection, offline UPI Lite X, and merchant intelligence. Two of the three are unbuilt. I documented them as roadmap in the case study, which is the honest treatment, and the more useful observation is why they were on the homepage at all.
They were there because AI was the part that made the product sound significant. The part that was actually built is a payments platform with a merchant dashboard, transaction view and device management, and the durable asset in that product is not a model. It is transaction history per merchant. Merchant intelligence is not an AI feature bolted on later; it is what that history becomes once enough of it exists. I had the sequence backwards in the marketing and roughly right in the code.
The second thing, less comfortable. Of everything I built between February and June 2026, almost all of it was features by the test in this article. The ones that would have been genuinely native depended on data I did not have access to, and in at least one case I found that out after building. Recognising the distinction on a whiteboard is easy. Noticing which side of it you are actually on, while you are enjoying the building, is harder.
The thing I would defend hardest: the correction loop is the cheapest durable advantage available to a small team right now, and hardly anyone is taking it. It requires no research capability and no capital. It requires deciding, in week one, to keep what your users fix.
Conclusion
Thin is not the problem. Substitutable is. A product built over a model captures value if something accumulates inside it that the provider does not have, and the three candidates are the workflow surface, the correction loop, and the integration and permission surface. Teece's framework predicted this before any of the current products existed, and the modularity literature explains why the value is moving where it is moving.
Feature and native are both legitimate. One borrows complementary assets that already exist, the other builds them from nothing. Choose on that basis, not on which one sounds more ambitious in a pitch.
Sources
- D. J. Teece, "Profiting from Technological Innovation: Implications for Integration, Collaboration, Licensing and Public Policy", Research Policy 15(6), 1986, 285–305.
- C. M. Christensen, M. Verlinden and G. Westerman, "Disruption, disintegration and the dissipation of differentiability", Industrial and Corporate Change 11(5), 2002.
- C. Y. Baldwin and K. B. Clark, Design Rules, Volume 1: The Power of Modularity, MIT Press, 1999.
- R. Sutton, "The Bitter Lesson", 2019. http://www.incompleteideas.net/IncIdeas/BitterLesson.html
- M. Iansiti and K. R. Lakhani, Competing in the Age of AI, Harvard Business Review Press, 2020.
- D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems", NeurIPS 2015: on entanglement between components. https://papers.nips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
- tapqr.live, homepage pillars "AI Fraud Detection", "Offline UPI Lite X", "Merchant Intelligence". Recorded as A25 in
SOURCE_INVENTORY.md. https://tapqr.live
Related reading in this archive
- What AI-native product management actually means
- Why I build many small products instead of one large one
- TapQR: the unbuilt AI pillars discussed above
- Inflio, tapbio and CreatorOS: the data-access failure
- Architecture at the model boundary: the technical form of the feature-versus-native question