The Commoditization Clock: When AI Eats Your Feature
The newest frontier model shipped native document handling, native browsing, a million tokens of context, and a fast tier that costs about a dollar for a million words of input. Somewhere, a founder read the release notes and felt their stomach drop, because half of what their product does just became a checkbox inside the thing they build on top of.
That founder is asking the wrong question. They want to know whether the model will eat their feature. It will. The only question that has ever mattered is how far above the waterline the rest of the product sits when it does.
I run two companies where AI writes most of the first draft of almost everything. I have shipped features that a model release made pointless inside a quarter, and I have shipped features that got cheaper and better every time the model improved. The difference was never how clever the feature was. It was whether the value lived in the model or in something the model could not reach.
Here is the flip that took me too long to accept. If a single model release can kill your product, you did not have a product. You had a feature the model had not gotten to yet, and you were renting time until it did. The work is not to hide from that. The work is to know exactly which parts of what you build are on a countdown, how fast that countdown runs, and where to move the value so the next release is a gift instead of a funeral.
This is a builder’s map for that. Not a moat lecture, a clock and a waterline you can actually run your own product through this afternoon.
- Every model release is somebody’s funeral
- The Waterline: what the model absorbs and what it can’t
- The Commoditization Clock: how fast is your feature’s countdown
- Five things the model can’t ship in its next release
- The Depth Test: product cycles or years
- Above and below the line, category by category
- Why a cheaper, better model is a gift if you’re above the line
- The contrarian take: the safest moat is the least impressive one
- What to do Monday morning
- FAQ
Every model release is somebody’s funeral
Start with the most expensive lesson in the wrapper era, because it is a clean one.
In October 2022, Jasper raised 125 million dollars at a 1.5 billion dollar valuation. It was the first serious AI writing tool, a unicorn inside eighteen months, and for a few weeks it looked like the template for the whole category. Six weeks later, ChatGPT launched. Same underlying model. Free. Jasper’s revenue peaked around 120 million dollars in 2023 and fell to roughly 55 million the next year. Monthly traffic dropped from 8.7 million visits to 6.1 million in two months. The company cut its own internal share value by twenty percent. Both co-founders stepped down.
Nothing about Jasper’s team got worse. The product did the same thing on Tuesday that it did on Monday. What changed is that the thing it did stopped being scarce, because the value of the product was access to a model, and the model became something anyone could reach for nothing.
This is not a one-time story. In November 2023, one file-upload feature inside ChatGPT erased dozens of “chat with your PDF” startups in an afternoon. Seventy-three near-identical clones had launched the same week the category peaked, and all of them woke up to find their entire pitch was now a paperclip icon in a text box. Across 2024, OpenAI’s steady drip of GPT Store, Operator, Tasks, Canvas, and Search cannibalized more than two hundred funded wrapper startups by most counts. The industry has a verb for it now. You get Sherlocked, named for the way Apple used to absorb popular Mac utilities into the operating system until the original apps had nothing left to sell.
The macro numbers make the pattern impossible to wave away. Analysts now expect somewhere between seventy and ninety percent of AI startups to fail or get acquired at soft valuations within eighteen months of founding. Thin wrapper businesses carry the model’s token cost on every single query, which drags gross margins down to around forty percent, well under the seventy to eighty percent a healthy software company runs on. I wrote about that margin math separately, and it compounds the problem here: the products most exposed to being eaten are also the ones with the least cash to survive the wait.
Founders tend to file this under platform risk, the fear that the vendor you depend on will turn around and compete with you. That is real, and I have covered it on its own. But absorption is a different and quieter threat. The model does not have to target you. It does not have to notice you exist. It just ships a generally useful capability in its next release, and your feature happens to be a special case of it. No malice, no strategy meeting about your startup. You were simply standing on a patch of ground the water was always going to reach.
The Waterline: what the model absorbs and what it can’t
Picture a rising waterline across your product. Everything below the line is what a general model can do with a single call and a good prompt. Everything above the line is what the model cannot reach no matter how good it gets, because the value does not live in the model at all. It lives in your data, your customer’s workflow, your distribution, or your willingness to be accountable for an outcome.
The line is not fixed. It rises with every release. Each model generation pulls another band of capability under the water: longer context drowns the “manage your documents for you” features, native tool use drowns the “connect two apps” features, a cheaper fast tier drowns anything whose only edge was being affordable. Your product does not move. The water does. Survival is a question of altitude.
The map sounds obvious until you run your own product through it honestly, and most founders flinch when they do. The feature they are proudest of, the one in the demo, the one the deck opens with, is almost always the one closest to a single API call. That is not a coincidence. The features that are easy to build and easy to show are easy for the model to absorb, because “easy to build on top of a model” and “already inside the model soon” are nearly the same sentence.
What sits safely above the line is usually the boring part. The integration nobody demos. The three years of labeled corrections your customers fed the product. The fact that you are the tool their team opens first every morning and files everything into. None of that photographs well. All of it is exactly what the model cannot ship in a release, because it does not live in the model.
Two clarifications keep this from turning into wishful thinking. First, above the line does not mean “not built with AI.” Every survivor I will name uses frontier models heavily. They just do not sell the model. They sell the thing wrapped so tightly around a workflow that the model is an ingredient, not the dish. Second, altitude is relative to the current water level, not a permanent grant. A feature that was two releases above the line in 2023 can be underwater now. This is the thin-versus-thick wrapper distinction made dynamic: the question is not whether you are a wrapper, almost everyone is, but how much dry ground you have between your value and the rising water.
The Commoditization Clock: how fast is your feature’s countdown
Knowing you are below the line is not enough. A feature that will be absorbed in five years and a feature that will be absorbed in the next release call for completely different decisions. One you can happily milk while you build the next thing. The other you should not have raised money on. So the second tool is a clock, and the clock runs at different speeds for different features.
Three signals set the speed. The closer a feature is to a single model call, the faster the clock, because the shorter the distance between “your product does this” and “the model does this,” the less work the vendor has to do to close it. The more visible and popular the feature, the faster the clock, because popularity is a market-research report the vendor reads for free, and popular categories are exactly the ones a platform ships to look generous. And the more obviously the feature sits on the vendor’s roadmap, the faster the clock, because a company that sells document handling is going to keep improving document handling whether or not you exist.
Run the audit below on the feature that carries your product. Be brutal, because the clock does not care about your roadmap.
| Signal | Fast clock (months) | Slow clock (years) |
|---|---|---|
| Distance to one API call | Prompt plus a single call reproduces the core | Dozens of integrations and steps stitched around the call |
| Visibility | Crowded, hyped category the vendor demos on stage | Unglamorous problem nobody puts in a keynote |
| On the vendor’s roadmap | A special case of what the model already sells | Off to the side of the vendor’s business |
| Switching cost for your user | They could leave over a weekend and lose nothing | Leaving means abandoning their data and rewiring their week |
| Data that improves with use | Every user gets the same generic model output | Your copy gets sharper the longer a customer stays |
The uncomfortable part of this audit is that raising money can move your clock the wrong way. Funding buys visibility, visibility draws the vendor’s eye, and a feature that might have quietly earned for years becomes a category the platform decides to own. I have watched founders treat a funding announcement as proof of a moat when it was closer to a starting gun. The whole point of an AI-native plan is to spend that attention buying depth faster than it buys you a target on your back.
Five things the model can’t ship in its next release
Above the line is not a vague promise about “adding value.” It is a short, specific list of things that do not live inside a model, cannot be trained into one from public data, and take a vendor years to build even if they decide to. There are only five that matter, and every AI company that survived a wave of absorption is standing on at least one of them.
| Above-the-line moat | Why the model can’t copy it | Receipt |
|---|---|---|
| Data you cause to exist | Trained on public text; your corrections, outcomes, and labels are private and only exist because your product ran | Harvey extracts tacit senior-partner legal reasoning that sits in no training set |
| Workflow lock-in | A model can answer a question; it cannot be the place a team files everything and runs its day | Cursor is the daily IDE for a slice of the world’s engineers, above 90 percent net dollar retention |
| Distribution it won’t copy | A channel or relationship the vendor can’t or won’t replicate without cannibalizing itself | Perplexity’s Comet browser and publisher revenue share own a lane the labs avoid |
| Accountability and execution | Someone has to be liable, integrate the mess, and make the outcome actually happen in the real world | Software that signs an SLA, touches money, or moves atoms, not just tokens |
| Regulated context | Compliance, permissions, and audit trails specific to one industry the general model won’t carry | Legal, medical, and financial verticals each need different data, controls, and proof |
The survivors make the list concrete. Cursor is, on paper, a wrapper around models it does not own, and it crossed roughly two billion dollars in annual revenue anyway while most wrappers died. The reason is not a secret model. It is that Cursor became the tool a large share of professional engineers open every single day, with proprietary retrieval and multi-file editing built around the model, and net dollar retention above ninety percent. When a new model ships, Cursor does not panic. It swaps the model in and gets better, because the value was never the model. The value was the workflow the model plugs into.
Harvey is the cleanest example of data you cause to exist. Instead of pointing a general model at public case law, Harvey partnered with elite law firms to pull out the tacit reasoning that lives in the heads of senior partners, the judgment that is nowhere in any training set because nobody ever wrote it down. Then it embedded that inside the actual case workflow, a step lawyers move through every morning, not a chat box in the corner they forget by week two. A better base model does not threaten that. It sharpens it.
Perplexity shows distribution as a moat. It closed 2025 above 330 million dollars in annual recurring revenue and raised a 500 million dollar round at an 11 billion dollar valuation, and it did that in the one place the model labs structurally hesitate to go: a consumer browser and a revenue-share program that pays the publishers whose content answers get built from. A frontier lab could copy the interface in a weekend. It will not copy a business that pays the press, because that tangles its own incentives. That is what “distribution the vendor won’t copy” means in practice, and it is why I keep telling founders that distribution is the moat that survives the model getting good.
The pattern under all three is the same. None of them sell intelligence. They sell a place the intelligence gets put to work, wrapped in data the model can’t see, a workflow it can’t occupy, or a channel it won’t enter. The data you cause to exist is the strongest of the five because it compounds. Every day a customer uses the product, the moat gets one day deeper, and the model, which improves for everyone equally, cannot close a gap that widens with your specific usage. Execution and regulated context matter too, and they connect to a truth I covered in the production gap: getting a model to answer is easy, getting it to be accountable in the real world is the part that takes years, and the part nobody can absorb from you in a release.
The Depth Test: product cycles or years
Put the two ideas together and you get a single test you can run in about ten minutes. One axis is how easily the model can substitute for your core. The other is how deep you sit in the customer’s data and daily workflow. Where your product lands tells you whether your survival is measured in product cycles or in years, and, more useful, which direction to move.
The bottom-left is where the funerals happen. Easy to substitute, shallow in the workflow, which is another way of saying the whole product is a single call the user could make themselves once the model makes it native. Jasper and the PDF-chat wave lived here. If you are honest and land here, do not raise a big round on it. Use whatever traction you have to buy your way up or to the right, fast.
The two off-diagonal corners are the traps that fool smart founders. Borrowed time looks safe because you are embedded, users are active, and retention looks fine, right up until the vendor ships the native version and your copyable core stops being a reason to stay. Feature-not-a-company looks safe because your tech is genuinely hard to copy, but hard-to-copy and hard-to-leave are different things, and a clever capability with no lock-in gets out-distributed by whoever reaches the customer first. The wrapper trap is really these two quadrants convincing you they are the top-right one.
Only the top-right buys years. Hard to substitute because the value is your data and your accountability, deep in the workflow because you are the system of record the customer runs on. Notice this is not the corner with the most impressive AI. It is the corner with the most boring lock-in. That inversion is the whole game, and it is why the flashiest AI demo is often the shortest-lived business.
Above and below the line, category by category
Abstractions are easy to nod along to and hard to act on, so here is the same product idea in two versions across six categories. The left column is the version that gets eaten. The right column is the same category built above the line. The underlying model is identical in both. Only the altitude changes.
| Category | Below the line (gets eaten) | Above the line (survives) |
|---|---|---|
| Writing | An AI writing tool: access to a model with a nicer box | The content system your team plans, drafts, and ships the whole week inside |
| Documents | Chat with your PDF | The system of record for a legal team’s contracts, clauses, and obligations |
| Search | An AI answer box over a public index | A browser plus a publisher network nobody else occupies |
| Coding | An autocomplete demo on top of a code model | The daily IDE with proprietary retrieval across the whole repo |
| Support | A support bot that answers from your docs | The ticketing system of record that owns every resolution your team has ever written |
| Meetings | A meeting summarizer | The CRM that files the summary into the right deal and moves it forward |
Read the right column again and notice what it costs. Every above-the-line version is more work, more boring, and worse in a demo. Nobody claps for “we are the system of record for contract obligations.” It does not fit in a tweet. It takes eighteen months of unglamorous integration before it looks like anything. That price is the moat. The reason the model can’t ship it in a release is the same reason it was hard for you to build, and if it had been easy, you would already be underwater.
Here is the move in practice, using a real shape I see constantly. A founder wants to build “chat with your HR policies,” an assistant employees ask about leave, benefits, and rules. That is a single call over a folder of documents, bottom-left, a clock measured in months. Watch it climb. Step one, stop being a chat box and become the place HR authors and versions the policies in the first place, so you own the source, not a copy of it. Step two, capture every question employees ask and every answer HR approves or corrects, so you accumulate a private record of what this specific company actually decides, which no base model has. Step three, act, not just answer: file the leave request, update the system, route the exception to a manager, so removing you means unwiring a process, not closing a tab. Same starting idea, now sitting in the top-right, with a clock measured in years, because the model getting smarter makes your version better instead of redundant.
This is also why “who is the buyer” changes the altitude. When the customer is a team that has to trust, audit, and be accountable for the output, the boring above-the-line work is the product. I went deeper on that shift in how the buyer itself is changing, and it points the same direction: the defensible version is always the one wound tightest around a specific customer’s reality.
Why a cheaper, better model is a gift if you’re above the line
The same release that holds a funeral for the thin wrapper throws a party for the company above the line. This is the part founders miss when they read model announcements with dread. Whether the next model is a threat or a windfall depends entirely on where your value sits, and the exact same news lands in opposite directions for the two.
Think about what a cheaper, faster, more capable model actually is if you are the system of record for a workflow. It is a discount on your single biggest variable cost, applied to every query, with zero work from you. Your customer stays because their data and their process still live with you. Their switching cost did not move. But the price you pay to serve them just dropped, and the quality of what you deliver just rose. For a thin wrapper carrying the token cost at forty percent margins, the model becomes free and the business evaporates. For a thick product, the model gets cheaper and the margin expands toward normal software economics. Same event, opposite outcome.
I have lived both sides of this. A feature I shipped whose only value was clean model access got worse every time the model improved, because “clean access” is exactly what the platform ships for free. A different product, where the model was one ingredient inside a workflow customers had poured a year of their own data into, got a little better and a little cheaper with every model generation while the customers did not go anywhere. Nothing about my effort separated those two. The first lived below the line and the second lived above it, and the water treated them accordingly.
This reframes how you should read a capability jump. A more capable model does not reduce the value of judgment, distribution, or proprietary data. It raises it, because it removes every constraint except those, and value flows to whatever is still scarce. The scarce thing is never the intelligence once the intelligence is a commodity you can buy by the token. The scarce thing is the specific data, the specific workflow, the specific relationship. Cheaper intelligence makes the scarce complements worth more, not less, which is the opposite of the panic the release notes produce.
It also changes your pricing. If your value is the model, you are forced into per-token or per-seat pricing that races the model’s own falling price to the floor, a race I broke down in the efficiency trap. If your value is the outcome you own above the line, you can price the outcome, and a falling model cost becomes margin you keep instead of a discount you are forced to pass on. That is the whole argument for rethinking how AI products should charge in one sentence: price the part of the stack that is yours, not the part you rent.
The contrarian take: the safest moat is the least impressive one
Most founders hear “build a moat the model can’t cross” and reach for the wrong tool. They assume it means go deeper into the technology, train a custom model, build something so advanced the frontier labs can’t match it. That is almost always a trap. You will not out-research OpenAI or Anthropic on raw capability, and any technical edge you find on the model itself has the fastest clock of all, because that is precisely the ground the labs are sprinting across. Competing with the water on being wetter is a losing game.
The safest ground is the least impressive. It is the boring integration into a workflow nobody wants to rebuild. It is the pile of proprietary corrections your customers generated that will never appear in a training set. It is the distribution relationship the vendor structurally will not enter. None of it is technically hard in the way founders find flattering, and all of it is the reason the survivors survived. I have had to un-learn my own instinct here more than once, because the impressive thing is seductive and the durable thing is tedious, and the water does not grade on seductive.
There is a second flip inside the contrarian take. Getting Sherlocked is not automatically death, and it can be a gift, if you are above the line. When the vendor ships a native version of what you do, it validates your category to millions of people at once and hands you every user whose needs run deeper than the generic feature. The shallow competitors die. You inherit the top of the funnel for free, because the native feature is the demo and you are the version that actually holds a team’s data and process. A native feature is a threat to the below-the-line clones and a lead-generation engine for the above-the-line company in the same category.
Now the honest counter, because the whole argument has a soft spot and I would rather name it than have it named for me. The tidy story is that models commoditize and value flows up to the application layer. Over a long enough horizon, most analysts expect that, with the application layer capturing more value than foundation models by around the end of the decade. But that is a forecast, and it is not where the value sits yet. The labs are still capturing an enormous share of the value they create. One major lab went from roughly nine billion dollars of annualized revenue to more than forty-four billion in about half a year, with inference gross margins above seventy percent. The model layer is not politely stepping aside to leave the application layer its margin. So do not build on the assumption that the water stops rising or that the labs stay in their lane. Build assuming the waterline keeps climbing for years and the vendor keeps expanding into your space, and make sure your dry ground is high enough to survive both. This is the builder-side mirror of the build-versus-buy decision your own customers are running on you: they are asking whether to keep renting your product or rebuild it themselves, and the answer is the same, whatever is truly yours stays above the line, and the rest is on a clock.
The deepest version of the safe-and-boring moat is human, and it is the one asset with no clock at all. The judgment to know which problem is worth solving, the taste to tell good output from confident garbage, the trust a customer places in you specifically. I made the full case for that in the taste moat, and it belongs here as the floor under everything else: the model can absorb a feature, but it cannot absorb the person a customer decided to rely on.
What to do Monday morning
This is a diagnosis you can run on your own product before lunch. It is uncomfortable on purpose, and the discomfort is the signal.
Draw your own waterline. List every feature your product has on one page. Next to each, write below or above, using one test: could a general model do the core of this with a single call and a good prompt? If yes, it is below the line. Be honest about the demo feature. It is almost always the first one underwater.
Score the feature that carries you. Take the one feature most of your value and revenue hangs on, and place it on the Depth Test. Easy or hard to substitute, shallow or deep in the workflow. If it lands anywhere but the top-right, you have found the thing to fix before you find anything else.
Run the clock. Put that same feature through the five-signal audit. Distance to one call, visibility, on the vendor’s roadmap, switching cost, data that improves with use. Three or more pointing to a fast clock means your planning horizon is product cycles, and you should act like it.
Write the funeral memo. Spend twenty minutes writing the announcement where your model vendor ships your core feature natively, for free, next month. Now list what in your business still stands after that release. That surviving list is your real product. Everything else was rented time. If the surviving list is empty, you just learned the most important thing you will learn all year, while there is still time to act on it.
Pick one climb and start it in the next ninety days. Choose a single above-the-line investment and begin. Start capturing the corrections and outcomes your product uniquely generates, so you own data that compounds. Or go one layer deeper into the workflow so you become the source, not a copy. Or build the distribution relationship the vendor will not touch. One climb, started now, beats a perfect moat strategy you admire on a whiteboard.
Stop selling the model. Go read your own homepage. If it sells access to intelligence, faster or cheaper or wrapped nicely, you are advertising the exact thing the platform gives away. Rewrite it to sell the workflow you own and the outcome you are accountable for. The words are a symptom, but fixing them forces you to find the value that is actually yours, or admit you have not built it yet.
None of this requires a better model, more funding, or a research breakthrough. It requires looking at your product the way the water looks at it, which is the one perspective founders avoid because it is the one that hurts. If you want the wider frame this sits inside, I keep it in the builder’s mental model for AI and mapped across the whole opportunity space in the AI opportunity map. The map changes, the water rises, and the only durable strategy is to keep asking which parts of what you build the model cannot reach.
Frequently asked questions
What does it mean to get “Sherlocked” by an AI model? Getting Sherlocked is when a platform ships a native feature that makes a third-party product redundant overnight. The term comes from Apple absorbing popular Mac utilities into the operating system. In AI, it happens when a foundation model adds a capability, like file upload or native browsing, that was an entire startup’s reason to exist. The product does not get worse. The thing it sold just stops being scarce, because the model now does it for free.
How do I know if my AI product will get commoditized? Run the clock-speed audit. The faster your feature can be reproduced with a single model call, the more visible and hyped its category, and the more clearly it sits on your vendor’s roadmap, the shorter your countdown. Add switching cost and whether your product improves with a customer’s own data. If most signals point to a fast clock, assume the native version ships within a few product cycles and plan accordingly.
Are AI wrapper startups a bad idea in general? No. Almost every successful AI company is technically a wrapper around models it does not own, including ones worth billions. The failure is not wrapping a model, it is thin wrapping, where a prompt and an interface over one API call is the entire product. A thick wrapper adds proprietary data, workflow lock-in, and distribution the vendor cannot copy, and that is just a normal software company that happens to use an LLM. The label does not decide your fate. Your altitude above the waterline does.
What are the moats that actually survive better AI models? Five hold up. Data your product uniquely causes to exist, workflow lock-in where you are the system of record, distribution the vendor will not copy, accountability and real-world execution, and regulated context specific to one industry. The strongest is the data you cause to exist, because it compounds with every day of usage while the model improves equally for everyone. What these share is that the value does not live in the model, so a better model cannot absorb it.
Does a more capable model help or hurt my startup? It depends entirely on where your value sits. If your value is clean access to a model, a better model competes with you and usually wins, because the platform ships that access for free. If your value is a workflow, a dataset, or a relationship the model plugs into, a better model is a discount on your costs and an upgrade to your output while your customers stay put. The same release is a threat below the line and a gift above it.
Should I still build in a category a big AI lab might enter? Yes, if you can get above the line before they arrive, and often the lab entering is what validates the category and sends you customers. The mistake is building the shallow version and hoping they do not notice. Build the version that owns data and workflow the lab will not chase, so when the native feature ships, it becomes your free top of the funnel instead of your obituary.
How is this different from platform risk? Platform risk is the fear that a vendor you depend on will deliberately compete with you or cut off your access. Commoditization by absorption is quieter and does not require any intent. The vendor ships a generally useful capability, and your feature happens to be a special case of it, so you are eaten without ever being targeted. You should plan for both, but absorption is the one founders underestimate because it feels impersonal, and it is.
What is the single fastest way to test my product’s exposure? Write the memo where your model vendor ships your core feature natively and free next month, then list what still stands. If little survives, your value lives below the waterline and your horizon is product cycles. If a lot survives, you have real dry ground and you should invest to raise it further. Twenty minutes with that memo tells you more than any market report.