The most expensive AI decision I have watched teams make is not which model to use. It is committing to build a capability that the market was about to commoditize, six months before a vendor shipped the same thing at a tenth of the cost. The second most expensive is the inverse: buying a packaged product to handle the one capability that was supposed to set the business apart, then discovering that the thing competitors could not copy is now identical to what they bought from the same vendor.
Both teams ran a build-vs-buy analysis. Both produced a spreadsheet. Both got the answer wrong because they were optimizing for the wrong axis — cost and speed — when the axis that actually mattered was strategic position and the rate at which the capability was changing underneath them.
This is a framework for the decision that comes before vendor selection. Not "which AI product should we buy," but the prior question: should this capability be built in-house, bought as a product, or composed from APIs at all? The answer is not static. It changes as the capability moves from differentiator to commodity over its lifecycle, and a decision that was correct at one point becomes a liability at another. The framework has to account for that motion, or it answers a question that has already expired.
Three Options, Not Two
The phrase "build vs. buy" hides a third option that has become the most common correct answer for AI capabilities, and naming it precisely matters because the three options carry very different cost structures and exit costs.
Build means you own the capability end to end. You collect or generate the training data, you select and fine-tune or train the model, you operate the inference infrastructure, and you maintain the whole thing as the underlying techniques change. Build gives you maximum control and maximum differentiation potential. It also gives you maximum ongoing cost — not the initial construction, which teams consistently overestimate, but the maintenance, which they consistently ignore. A built AI capability is a permanent engineering commitment, because the field moves and a model that is competitive today degrades into a liability within a year if no one is funding its upkeep.
Buy means you license a packaged product that solves a defined problem. A fraud-detection service, a transcription product, a customer-support automation platform. You get time-to-value measured in weeks instead of quarters, and you transfer the maintenance burden to the vendor, who amortizes it across all their customers. What you give up is differentiation — by definition, every competitor can buy the same product — and you take on switching cost and integration cost that the purchase price rarely reflects. Buying does not remove the engineering work; it relocates that work to the boundary between your system and the vendor's.
Compose means you assemble the capability from general-purpose AI primitives — foundation model APIs, embedding services, vector stores, orchestration layers — wiring them into a system that is specific to your problem without owning any of the underlying models. Compose is the middle path that AI made viable in a way it never was for traditional software. You get most of the differentiation of build, because the system you assemble around the primitives is yours, while paying for the model capability on consumption terms and inheriting the vendor's continuous improvement of the underlying model for free. The tradeoff is dependency: your capability rides on infrastructure you do not control, with pricing and availability you cannot fully predict.
The error I see most often is treating this as a binary when the right answer is almost always compose at the start, with a deliberate decision about whether and when to migrate toward build. Most teams skip compose entirely. They debate build versus buy, choose one, and commit capital to a decision that a composed prototype would have informed for a fraction of the cost.
The Dimensions That Should Drive the Decision
Cost and time-to-value are the dimensions teams reach for first, and they are the least useful for the actual decision. They are real constraints, but they are downstream of the dimensions that determine whether you should be building at all. There are six that matter, and the first two outweigh the rest.
Strategic differentiation is the dimension that should be evaluated before any other, because it determines whether the entire build conversation is even legitimate. The question is narrow: does this specific capability make your business meaningfully harder to compete with? Not "is AI strategic to us" — that question is too broad to answer and almost always returns yes, which is why it is useless. The useful question is whether this particular capability is something customers choose you for, or something they assume you have. A logistics company's route-optimization model may be a genuine differentiator. Its meeting-transcription tool is not, no matter how much AI is involved. That classification decides everything downstream.
Rate of change is the dimension that most directly governs build risk, and it is the one teams most consistently misjudge. If the underlying technique for a capability is changing every few months — as foundation models still are — then anything you build is depreciating from the moment you ship it. Building against a fast-moving substrate means committing to a treadmill of re-engineering just to stay level with vendors who are funding that treadmill as their core business. When the rate of change is high, composition wins almost regardless of strategic value, because composition lets you inherit the improvement instead of chasing it. Build becomes defensible only when the rate of change slows enough that your investment can compound rather than erode.
Data sensitivity can override both of the above. If the capability requires processing data that cannot leave your control — regulated health records, proprietary financial models, anything where the data itself is the competitive asset — then buying a product that exfiltrates that data to a vendor is off the table, and even composition requires careful attention to what crosses the boundary. Sensitivity does not automatically mean build; it means the buy and compose options narrow to vendors with the contractual and architectural guarantees the data requires, and sometimes that set is empty.
In-house capability is the honest assessment of whether your team can actually build and, more importantly, maintain what you are proposing to build. This is where build decisions quietly fail. A team builds a capability during a period of focus and capacity, then attention moves to the next priority and the built system enters slow decay with no one funding its upkeep. If you cannot commit to a maintenance owner for the lifetime of the capability, you cannot build it — you can only construct it and watch it rot.
Switching cost applies most sharply to buy. The purchase price is visible; the cost of leaving is not. A bought capability that embeds itself deeply into your workflows, holds your data in its format, and shapes your processes around its assumptions becomes expensive to replace long before anyone notices the dependency forming. Switching cost is the hidden tax on buy, and it compounds: the longer you stay, the more expensive leaving becomes, which is precisely the dynamic vendors design for.
Time-to-value is the dimension that should break ties, not drive decisions. When two options score similarly on the dimensions above, the one that delivers usable capability sooner usually wins, because earlier delivery generates learning that improves every subsequent decision. But time-to-value used as the primary axis is how teams end up buying differentiators — the fast option is rarely the differentiating one, and optimizing for speed alone optimizes you toward the commodity.
A Framework You Can Actually Apply
The dimensions resolve into a sequence, and the order is load-bearing. Run them in this order and the decision usually makes itself; run them out of order and you optimize the wrong thing.
First, classify strategic differentiation. Is this capability a differentiator that customers choose you for, or a commodity they assume you have? Be ruthless here, because the natural bias is to overstate differentiation — every team believes its work is special. The test: if a competitor had the identical capability tomorrow, would you lose customers? If the honest answer is no, it is a commodity, and the build conversation is over before it starts.
Second, for commodities, choose between buy and compose on integration cost. Commodities should never be built. The choice is whether a packaged product or a composed assembly fits your system better. Buy when a mature product exists that matches your problem closely and the switching cost is acceptable. Compose when no product fits cleanly, when you need control over the integration surface, or when the commodity capability still needs to be wired tightly into proprietary workflows.
Third, for differentiators, evaluate rate of change before committing to build. A differentiator on a fast-moving substrate is still a poor build candidate, because the substrate erodes your investment faster than the differentiation compounds. When the underlying technique is volatile, compose the differentiator from primitives and own the assembly, not the models. Reserve build for differentiators where the technique has stabilized enough that your investment will compound — where what you build this year is still an asset next year rather than a maintenance burden.
Fourth, validate against in-house capability and maintenance commitment. Before any build decision is final, name the person or team who will own maintenance for the capability's lifetime, and confirm the budget for it exists. If you cannot, downgrade the decision to compose. This single check prevents the most common build failure, which is not building badly but building something no one is funded to keep alive.
The framework is deliberately sequential rather than a weighted score, because a weighted score lets a high time-to-value number rescue a capability that failed the differentiation test — which is exactly the failure mode the sequence is designed to prevent. Strategic position gates everything. Rate of change gates build. Maintenance commitment is the final veto. Cost and speed inform the choice within those gates; they never override them.
Compose Now, Build Later
The most useful pattern I have seen — and the one that resolves the tension between wanting differentiation and fearing the build commitment — is a deliberate migration: compose first, build only when the evidence justifies it.
The logic is that composition front-loads almost none of the cost and almost all of the learning. When you compose a capability from foundation-model APIs, you discover what the capability actually needs to do, where the real value sits, what the usage volume is, and whether the capability is a differentiator in practice rather than in the planning document. You learn all of this on consumption pricing, with no capital committed to infrastructure or training, and with the option to walk away cheaply if the capability turns out to matter less than expected.
You migrate from compose to build only when specific signals appear, and the signals have to be observed, not anticipated. The first is volume: when your consumption cost on the composed version grows large enough that owning the capability would be cheaper at your scale, the economics start to favor build — but only if the other signals are also present. The second is divergence: when the generic primitive no longer fits your problem well, when you are working harder and harder to bend a general-purpose model toward a specific need, the case for a purpose-built capability strengthens. The third is stabilization: when the underlying technique stops moving fast enough that a built version will hold its value rather than depreciating immediately.
When all three appear together — high volume, genuine divergence from the generic primitive, and a stabilized technique — the composed version has already paid for the learning that de-risks the build. You are no longer building on a hypothesis. You are building a capability you have operated, measured, and understood, against a substrate that has stopped shifting underneath you. This is the inverse of the failure mode at the start of this article: instead of committing to build before the capability was understood, you commit only after composition has told you exactly what to build and proven it is worth building.
The discipline this requires is resisting the build instinct early. Engineering teams want to own things; building feels like progress and renting feels like dependency. But building before the learning is in is how teams construct capabilities that the market commoditizes underneath them. Compose-now-build-later sequences the commitment to follow the evidence rather than the instinct.
The Mistakes That Recur
Across the programs I have delivered, the build-vs-buy errors cluster into a small number of recurring patterns, and naming them precisely is the cheapest prevention available.
Building commodities is the most expensive mistake and the most common among strong engineering teams, because the capability to build creates the temptation to build. A team that can build a transcription pipeline, a generic recommendation engine, or a standard document classifier often does, reasoning that they can do it better or cheaper than a vendor. They almost never can, because the vendor amortizes the capability across thousands of customers while the team carries the full maintenance cost alone. The capability that felt like an asset becomes a permanent tax on engineering attention, diverting the team from the differentiators only they can build.
Buying differentiators is the inverse and arguably worse, because it surrenders the thing that was supposed to make the business defensible. A company whose competitive edge depends on a specific capability buys that capability from a vendor — which means every competitor can buy the identical capability, and the differentiation evaporates the moment the vendor signs the next customer. The capability still works. It just no longer distinguishes you, and you have paid to commoditize your own advantage.
Ignoring the integration and maintenance cost of buy is the quietest mistake, because buy is sold as the low-effort option. The purchase price is presented as the cost, but the real cost is the integration work to wire the product into your systems, the ongoing work to keep that integration alive as both the product and your systems change, and the eventual switching cost when the product no longer fits. Buy is engineering work relocated, not eliminated. Teams that budget only for the license and not for the integration discover the true cost after they have already committed.
Treating the decision as permanent underlies all of the above. The right answer for a capability changes as it moves through its lifecycle — what should be composed today may merit building next year, and what was correctly built two years ago may be a commodity that should now be bought. A build-vs-buy decision made once and never revisited becomes wrong not because the analysis was flawed but because the world moved. The capability needs a periodic re-examination against the same framework, because its position on every dimension that mattered is in motion.
The Lifecycle Is the Real Variable
Every capability moves along the same arc, and the arc is what makes a single correct answer impossible. A capability that is a genuine differentiator today, built on a technique that is changing fast, is a compose candidate now. As the technique stabilizes and the capability proves its value, it may become a build candidate. As the market catches up and the capability becomes something every competitor assumes you have, it becomes a commodity — and the built version that was once a differentiator is now a maintenance burden that should be replaced by a bought product, freeing the team to build whatever the new differentiator is.
The framework works as a lens you re-apply as the capability ages, never as a one-time gate, because the dimensions that determine the answer — strategic differentiation, rate of change, the economics of owning versus renting — are all functions of where the capability sits in its lifecycle. A decision audit that asks "is this still the right answer" once a year is worth more than a perfect analysis done once and frozen.
This is why cost and speed make poor primary axes. They are the most stable-feeling dimensions, which is exactly why teams anchor on them — and they are the dimensions least connected to where the capability is heading. A composed capability that costs more per unit today may be the correct answer precisely because it preserves the option to build later when the evidence is in, or to walk away cheaply if the capability matters less than expected. Optimizing for today's unit cost forecloses the optionality that the lifecycle demands.
Decide by Position, Then Decide Again
The principle that resolves the whole framework is this: decide by strategic position and rate of change, not by cost and speed, and decide again as both of those move. Build the differentiators whose technique has stabilized and whose maintenance you can fund. Buy the commodities a vendor fits cleanly. Compose everything in between, and treat composition as the default that buys you the learning to make every later decision correctly.
The two teams at the start of this article did not lack analysis. They lacked the right axis and a sense of motion. One built against a substrate that was about to commoditize; the other bought away the one thing it should have owned. Each made a defensible decision against the wrong question, and each froze that decision while the capability kept moving. The build-vs-buy question has no permanent answer because no capability holds still — and the teams that get it right are the ones who stopped looking for a permanent answer and built the habit of asking again.
