TL;DR: Most AI build proposals are priced against a differentiation window that won’t exist by the time the capability ships. The cost of misreading that window isn’t just the build budget — it’s the team you redirected, the partnerships you didn’t sign, and the credibility you spent defending a moat that evaporated on a release note. What follows isn’t a forecast. It’s a pressure-test you can apply to a live proposal this week: four observable signals, a three-tier durability classification, and a checklist that survives a CFO conversation.
The capability you’re about to fund is being built somewhere else
Every week I sit across from leaders weighing a build proposal whose numbers only work if the capability stays proprietary for three to five years. The proposal is usually well-reasoned. The team is credible. The math is clean. And the assumption underneath it — that this capability will remain a differentiator long enough to earn back the investment — is almost never tested with the rigor applied to every other line in the model.
This is the gap where AI strategy and AI execution diverge. Strategy asks whether the capability matters. Execution asks how long it stays yours. The second question is where most build decisions quietly fail, because the people best positioned to answer it — the team that wrote the proposal — have every incentive not to.
The lens in this guide closes that gap. It doesn’t tell you what to build. It tells you how long what you build will remain yours, which is the only number that makes the rest of the model honest.
What “commoditized” actually means in an AI context
Before the signals are useful, the term has to be precise. A capability is commoditized when it becomes available at near-zero marginal cost through a foundation model API, a hyperscaler managed service, or a mature open-source implementation — to the point that building it in-house no longer produces a defensible advantage on quality, latency, or cost.
This is narrower than “someone else can do it.” Commoditization is the moment the capability stops being a reason customers choose you, because your competitors can reach the same outcome by writing a check or pulling a package. It is the moment the build-versus-buy question answers itself, even if your team hasn’t admitted it yet.
The timeline that matters for most enterprise AI decisions is eighteen months. That’s roughly the gap between a serious build kickoff and a production-grade rollout at scale. If the capability commoditizes inside that window, you are paying full price to ship a feature your competitors will get for free.
Four signals that a capability is heading toward commoditization
The signals below are not predictions. They are observable today, in public sources, by anyone willing to look. When two or more appear together on the same capability, the commoditization curve is steepening fast — and the eighteen-month window is the one being closed.
Signal | What you're watching for | Why it matters |
|---|---|---|
Foundation model release notes | The capability appears natively in two or more frontier providers within six months | The primitive is being absorbed into the model layer |
Hyperscaler managed services | AWS, Google Cloud, or Azure ship a preview service | Preview-to-GA is typically 9–12 months |
Startup capital convergence | Three or more Series A/B raises on the same primitive in a quarter | The category is forming; the moat is closing |
Open-source maturity | ~10k+ GitHub stars or integration into LangChain, LlamaIndex, Hugging Face | The floor on the capability has dropped to engineering time |
Signal one: the capability is showing up in foundation model release notes
When a capability you intend to build appears as a native feature in the release notes of two or more frontier model providers within a six-month window, the underlying primitive is being absorbed into the model layer. Structured output, tool use, long-context retrieval, basic agentic loops, vision grounding, and code execution all followed this pattern. Each was a credible build proposal eighteen months before it became a checkbox.
The OpenAI and Anthropic model cards and release notes are public. Read them as a competitive intelligence feed, not a product announcement. Anthropic’s Claude release notes and the OpenAI platform changelog are the cheapest pattern-recognition tool you have.
Signal two: hyperscaler managed services are in preview
If the model layer tells you where the primitive is going, the hyperscaler layer tells you when it arrives in procurement. When AWS, Google Cloud, or Azure announces a managed service that wraps the capability, the eighteen-month window is already half gone. Preview-to-general-availability is typically nine to twelve months. General availability is the moment your CFO will ask why you are running infrastructure to do what a procurement contract could deliver.
Hyperscaler product roadmaps are the single most reliable forward indicator of enterprise AI commoditization, because they are downstream of customer demand signals the providers have already validated at scale. If the capability is in preview, the demand has been proven.
Signal three: multiple well-funded startups are converging on the same primitive
When three or more Series A or B startups raise on the same capability description in a single quarter, that capability is a category, not a moat. Capital is the most honest signal in the ecosystem — it reflects where pattern-matching investors see a market gap that will close. The gap closes by one of three paths: a startup wins, the hyperscalers absorb it, or the foundation models include it natively. In all three paths, your in-house build loses its differentiation.
Public funding databases and the major venture newsletters surface this within days. Crunchbase and PitchBook are the obvious sources; the Stanford AI Index tracks aggregate investment patterns by capability area and is updated annually.
Signal four: open-source reference implementations are gaining traction
The final signal sets the floor. When a credible open-source implementation of the capability crosses roughly ten thousand GitHub stars or is integrated into a major framework (LangChain, LlamaIndex, Hugging Face Transformers, the major agent frameworks), the cost of replication has dropped to engineering time. Open-source maturity does not eliminate the build case — operational excellence still matters — but it changes the question from “can we build this?” to “is our operational layer worth eighteen months of effort?” That is a much harder question to answer yes to.
Three tiers tell you what kind of build you’re really funding
Signals tell you what’s happening to a capability. Tiers tell you what to do about it. Every AI capability under consideration falls into one of three durability tiers, and the tier determines the question you should be asking, the budget posture, and the language for the board.
Tier | Signals firing | Right posture | Where the build budget goes |
|---|---|---|---|
Commodity-bound | Two or more | Buy or wait | Nowhere — redirect the team |
Contested | One, plus proprietary data or workflow | Narrow scope | Only the defensible layer |
Durable-differentiator | Zero, with structural advantage | Fund fully and defend | The full stack, aggressively |
Tier one: commodity-bound
A commodity-bound capability is one where two or more of the four signals are already firing. The capability will be available through a foundation model API, a hyperscaler managed service, or a mature open-source package within twelve months. Building it in-house produces no durable advantage on quality, latency, or cost.
The right posture here is buy or wait. The wrong posture — the one I see most often — is to build it anyway because the team is already staffed and the proposal is on the table. That is sunk-cost reasoning dressed as strategy.
Tier two: contested
A contested capability is one where one signal is firing, or where the capability sits on top of a commoditizing primitive but adds operational complexity, proprietary data integration, or domain-specific workflow that the platforms are unlikely to address in the next eighteen months. Contested capabilities can be durable, but only if the build is scoped tightly around the part that does not commoditize.
The right posture is narrow scope. Build the thin layer that is genuinely yours; buy or borrow everything underneath. Most contested builds fail because they try to own the full stack and end up rebuilding the parts that commoditize while underinvesting in the part that does not.
Tier three: durable-differentiator
A durable-differentiator is a capability whose value comes from something a foundation model or hyperscaler structurally cannot provide: proprietary data at scale, deeply embedded workflow integration, regulatory positioning, network effects, or a customer relationship that the platform cannot replicate. None of the four signals are firing in a way that threatens the core of the advantage.
This is where build budgets earn their return. Durable-differentiators are rare. Most proposals labeled as such are actually contested capabilities in an optimistic frame — which is precisely why the second-order costs of misreading the tier are so much larger than the build budget itself.
The second-order effects of misreading the curve are worse than the build cost
The build budget is the visible cost. The hidden costs are larger and harder to recover.
The team you assigned to the commodity-bound build is the team you did not assign to the durable-differentiator. Senior AI engineers are the constraint in your organization, not capital. Misallocation here is the most expensive line item in your AI strategy, and it never appears in the build proposal.
Team morale compounds the cost. Engineers know when they are building something the platforms will give away. The good ones leave. The ones who stay learn that the organization cannot read the market, which calibrates every subsequent build decision downward.
Vendor lock-in to your own infrastructure is the quiet failure mode. Two years into a commodity-bound build, you have a system that requires ongoing engineering investment to keep parity with the free version your competitors are using. The off-ramp gets more expensive every quarter you delay it.
The reputational cost on the next AI proposal is real. A board that watched the last build commoditize will discount the next one, even when the next one is genuinely durable. You will have to overspend on diligence to recover the credibility.
The pressure-test checklist
The framework only matters when it touches a live proposal. Apply this to the one on your desk now. Each item is a yes-or-no question. The pattern of answers tells you the tier and the right posture.
Capability description
Write the capability in one sentence, in language a non-technical board member would understand. If it takes more than one sentence, the proposal is not yet ready to evaluate.
Example: “An AI agent that reads inbound enterprise sales emails, extracts intent, drafts a tailored response, and routes the deal to the right account executive.”
Signal check
Has this capability appeared in foundation model release notes from two or more frontier providers in the last six months? Yes / No
Is there a hyperscaler managed service for this capability in preview or general availability? Yes / No
Have three or more well-funded startups raised on this capability description in the last two quarters? Yes / No
Is there a credible open-source implementation with material traction (~10,000+ stars or integrated into a major framework)? Yes / No
Example answers for the sales-email agent: Yes, Yes, Yes, Yes. All four signals firing.
Durability classification
Two or more “Yes” answers → commodity-bound
One “Yes” answer, with proprietary data or workflow on top → contested
Zero “Yes” answers, with structural advantage from data, regulation, network effects, or embedded workflow → durable-differentiator
Example: sales-email agent classifies as commodity-bound. The capability will be available through platform APIs and managed services well inside the eighteen-month build window.
The defensibility question
Name the specific component of the build that a foundation model, a hyperscaler, and a well-funded startup cannot replicate in eighteen months. If you cannot name it in one sentence, the proposal is commodity-bound regardless of what the team says.
Example: “Our proprietary deal-stage data and the workflow integration into our existing CRM customizations.” This is the contested layer. Everything else in the proposal commoditizes.
The scope-narrowing test
If the classification is contested, what is the smallest possible build that owns only the defensible component? Strip the proposal down to that core. Everything else gets bought, partnered, or deferred.
Example: Build only the proprietary data layer and the CRM workflow integration. Use a foundation model API for the email reading, intent extraction, and drafting. Total scope reduction: roughly 70% of the original proposal.
The recommendation
Based on the tier, write the one-sentence recommendation for the executive sponsor. Commodity-bound → buy or wait. Contested → narrow scope and proceed. Durable-differentiator → fund fully and defend aggressively.
Example: “Recommend buy posture for the email-handling and drafting components via a foundation model API; build only the CRM workflow integration in-house, with a six-month review checkpoint.”
The checklist is deliberately short. The discipline is in answering the signal questions honestly, which the team that wrote the proposal often cannot do alone. Bring in a second reader who has no stake in the build.
Common failure modes
Even with the checklist in hand, the framework breaks when leaders misapply it in predictable ways. Each of the patterns below is a place where the discipline slips and the classification drifts upward toward the answer the team wanted.
Treating the signals as predictions instead of observations. The signals are public facts about what is shipping today, not bets on what will ship tomorrow. Teams that argue with the signals are usually arguing with reality. Listen to what the platforms are already doing, not what you hope they will not do.
Misclassifying contested as durable. This is the most common error. The team sponsoring the build wants the proposal to clear the bar, and “durable” is the bar. The discipline is to ask: what specifically would the foundation model providers and hyperscalers have to fail to do for this to remain a differentiator in eighteen months? If the answer requires them to ignore an obvious market, the capability is contested at best.
Confusing operational excellence with structural advantage. Running a capability well is not the same as owning a capability the platforms cannot replicate. Operational excellence is table stakes; it is not a tier-three classification. If the only advantage is “we will run it better,” you are funding a contested build at best, and a commodity-bound build more often.
Letting sunk cost decide the tier. A project that is six months in does not get reclassified upward because the team has already done the work. The signals are the signals. The right move on a commodity-bound build mid-flight is to stop, harvest what is reusable, and redirect the team. That conversation is hard. It is also the one that separates the leaders who get AI right from the ones who explain afterward.
Treating the eighteen-month window as fixed. For some capabilities the window is six months. For others it is three years. The four signals will tell you which, if you read them honestly. Do not anchor on eighteen months when the evidence says otherwise.
How to bring the assessment into the board conversation
The framework lives or dies in the room where the build gets approved. The board does not need the checklist. They need the one-page version, in language that holds up under CFO scrutiny.
Open with the capability, the proposed investment, and the durability classification in three sentences. Name the specific component that constitutes the defensible advantage, or state plainly that no such component exists. Quantify the cost of misreading the curve — not just the build budget, but the engineering capacity redirected from durable work. Close with the recommendation: buy, narrow, or build fully, with the review checkpoint at which the classification gets re-tested against the signals.
The language that survives the room is declarative. “The four observable signals indicate this capability will be available through platform APIs inside our build window. The defensible component is the proprietary data integration, which represents roughly thirty percent of the proposed scope. We are recommending we narrow the build to that component and buy the rest, with a six-month signal review.” That sentence has been pressure-tested. It does not predict. It observes, classifies, and recommends.
The CFO is not skeptical of AI investment. The CFO is skeptical of investment in capabilities that commoditize before they ship. Give them the lens, and the conversation changes.
The capability stays yours only as long as the platforms let it
The point of the framework is not to discourage building. It is to make sure the build budget is spent on the thirty percent of the proposal that will still be a differentiator in eighteen months, instead of the seventy percent that the platforms will absorb. Most organizations have the resources to fund a few genuinely durable builds. They do not have the resources to fund the rest and still execute on what matters.
The pressure-test takes an hour. The build it correctly redirects pays for itself many times over. Pull the checklist into your next build review and run it on the live proposal. The signals are public. The classification is honest. The recommendation defends itself.
FAQ
Q: How do I tell which AI capabilities will be commodities in 18 months?A: Watch four observable signals: appearance in foundation model release notes from two or more frontier providers, hyperscaler managed services in preview, three or more well-funded startups converging on the same primitive, and credible open-source implementations gaining traction. When two or more signals fire on the same capability, the eighteen-month commoditization window is closing.
Q: What is the difference between a commodity-bound and a durable-differentiator AI capability?A: A commodity-bound capability has two or more commoditization signals firing and will be available through a platform API, managed service, or open-source package inside the build window. A durable-differentiator has zero signals firing and gets its value from proprietary data, embedded workflow, regulatory positioning, or network effects that the platforms structurally cannot replicate. Contested capabilities sit between the two — usually durable only in a narrow, scoped-down form.
Q: How do I pressure-test an AI build proposal against the commoditization curve?A: Write the capability in one sentence. Run the four signal questions. Classify into commodity-bound, contested, or durable-differentiator. Name the specific defensible component in one sentence — if you cannot, the proposal is commodity-bound. For contested capabilities, narrow scope to only the defensible component. Bring in a second reader with no stake in the build to answer the signal questions honestly.
Q: How do I explain AI commoditization risk to my board or CFO?A: Lead with the classification and the recommendation in three sentences. Name the defensible component and quantify it as a percentage of the proposed scope. Frame the cost of misreading the curve in terms of redirected engineering capacity, not just build budget. Recommend buy, narrow, or build fully, with a six-month signal review checkpoint built into the plan. Declarative language survives the room; hedged language does not.
Q: What are the second-order effects of building on the wrong side of the commoditization curve?A: The visible cost is the build budget. The larger costs are the senior engineers redirected away from durable work, the team morale that erodes when engineers know they are building what the platforms will give away, the ongoing infrastructure burden of maintaining parity with a free version, and the credibility cost on the next AI proposal. Senior AI engineering capacity is the binding constraint in most organizations, which makes misallocation more expensive than the line-item budget suggests.
Q: Should the eighteen-month window be treated as fixed?A: No. Eighteen months is a useful default because it approximates the gap between a serious build kickoff and a production-grade rollout at enterprise scale. For some capabilities the commoditization window is six months; for others it is three years. The four signals tell you which. Read the signals honestly and let them set the window for the specific capability, rather than anchoring on the default.
I unpack observations like this every week in Operator’s Log. Grounded AI perspective from the operator’s seat. Free. Subscribe →