The classic build-vs-buy decision has a tidy answer: build what differentiates you, buy what doesn't. For traditional software it mostly worked, because the cost of building was knowable, the cost of buying was knowable, and the things that differentiated a company stayed differentiated long enough to amortize the build.

AI breaks the rule from multiple directions at once. The foundation models that differentiated companies six months ago are commodity today. The tools that were "just buy it" turn out to require so much custom integration that they end up costing more than building. The hosted vendor that was a safe choice is acquired, or pivots, or deprecates the API the use case depended on. The build that was supposed to be a moat is matched by a vendor's next release.

The right framework for AI build-vs-buy looks nothing like the one most teams are still using. The question has changed; the answer is no longer where most teams instinctively look.

Why the Old Framework Fails for AI

The traditional build-vs-buy heuristic relies on three assumptions, all of which hold for ERP and break for AI.

Commoditization timelines have collapsed. In traditional software, a category took years to commoditize. A team could safely build something custom on the assumption that the differentiation would last long enough to pay back the investment. With AI, a capability that is novel in Q1 is a feature on every vendor's roadmap by Q3. The window for proprietary advantage at the model layer is now measured in months.

Build costs went down; integration costs went up. Foundation models, open weights, and tooling have made it dramatically cheaper to stand up an AI feature in isolation. What hasn't gotten cheaper is the work of connecting that feature to real enterprise data, real workflows, and real users. The cost of the model is rounding error; the cost of integration is most of the program.

Vendor risk is materially higher than in traditional SaaS. The vendor that runs your CRM in 2026 will probably still exist in 2030. The vendor that runs your AI orchestration in 2026 may have been acquired, repositioned, or shut down by 2028. Build-vs-buy decisions made on the assumption of vendor permanence are mispricing a real risk.

The differentiation surface keeps moving. What differentiates a company changes as the technology moves. Two years ago, the differentiator was having any AI in the product. Last year, it was the model choice. This year, it is the data, the integration, and the workflow design. A build that locked in last year's differentiator is now a commodity feature with custom maintenance.

The Real Layers — Where Each Decision Lives

The honest build-vs-buy question is no longer "AI: build or buy?" — it is a separate question for each layer of the stack, and the answers are different at each layer.

Models: almost always buy. Building your own foundation model is a fool's errand for the vast majority of organizations. The capital required, the talent density needed, and the rate of model improvement at the frontier mean that even a successful build will be behind within months. The vanishingly small set of companies that should build their own models know who they are.

Orchestration and platform: contested. Whether to build orchestration (routing, evaluation, prompt management, tool calling) or buy it depends on scale and specificity. At low volume, buy. At scale with specific requirements that vendors don't meet well, build — but build it as a platform, not as one-off plumbing.

Application logic: build the specialized, buy the generic. A generic customer-support tool with AI inside it should be bought. A specialized application that encodes your specific workflow, your domain rules, and your business judgment should be built — because the value lives in the specifics, and a vendor can't sell you specificity that they had to learn from your competitor.

Data and integration: always build. Your data is yours. The integration to your systems is yours. No vendor will build it for you in a way that you can confidently keep when you swap the rest of the stack. The data and integration layer is where durable value compounds, and it is where most companies under-invest.

Workflow and judgment: build. The way your sales team qualifies opportunities, the way your support team escalates, the way your finance team reviews. These are encoded business judgment, and they should not be outsourced to whichever vendor happens to be in market this year.

Where Teams Default Wrong

The build-vs-buy mistakes are not random. Different functions make different errors in the same direction, and they cancel out badly.

Engineering teams over-build at the model and orchestration layers. Engineers love the technical problem at the model layer and underweight how fast vendors will catch up. They build infrastructure that becomes table-stakes within a year and is then a maintenance burden no one wants. The build-vs-buy framework needs to discount for the rate of vendor catch-up at lower layers.

Business teams over-buy at the application and workflow layers. Business leaders are uncomfortable with the timeline and risk of building, so they reach for vendor solutions even where the value is specific to their company. The vendor solution then forces the company's workflow to conform to the vendor's assumptions — and the differentiation that could have been built is given away.

Both leave value on the table. Engineering builds the wrong things; business buys the wrong things; the parts that should have been built specifically aren't, and the parts that should have been bought commoditized aren't. The result is an architecture that is both over-engineered and under-differentiated.

A Decision Process That Holds Up

The companies handling build-vs-buy well have replaced the binary question with a structured process that operates at each layer separately.

Start with reversibility. The most important question for any AI decision is how hard it would be to undo. A reversible buy (a vendor you can swap) is a different decision than an irreversible buy (data trapped in a proprietary format). Same for build: a build that creates portable, owned IP is different than a build that creates technical debt. Reversibility is more important than cost.

Identify your durable differentiation. What about your business will still differentiate you in five years? The data you have access to. The relationships you've built. The workflows that encode your domain expertise. Build there. Buy everywhere else.

Buy the moving parts; build the sticky ones. Anything that will be improving rapidly at the vendor level (models, generic orchestration, evaluation tooling) should be bought, because your build will not keep pace. Anything that compounds with your own data and workflow over time should be built, because that's where the moat actually accumulates.

Negotiate exit terms before signing. Data portability, model portability, integration portability. The cost of switching should be a contract term, not a discovery in year three. If a vendor won't agree to reasonable exit terms, that's the signal — they know what they're locking you into.

Reassess every six months. The build-vs-buy answer for any layer can change as the market moves. A build that made sense last year may now be a maintenance burden because a vendor caught up. A buy that made sense last year may now be a liability because the vendor pivoted. The reassessment cadence has to match the rate of change in the market.

The Stakes

The companies that get build-vs-buy right in AI are not just saving money. They are accumulating the right things over time — proprietary data, integration depth, workflow specificity, the small set of capabilities that genuinely differentiate them — and they are buying the things that would have been wasted effort to build. Their architectures get stronger over time.

The companies that get it wrong end up with an architecture that has the opposite shape. They've built commodity infrastructure that vendors now do better, and they've bought differentiation that they could have owned. They have maintenance debt at the bottom of the stack and vendor lock-in at the top. Every six months the gap with the companies that got it right grows.

Build-vs-buy decisions in AI are not isolated procurement events. They are architectural commitments that compound. The companies treating them that way are pulling ahead. The companies still running the old framework are accumulating the wrong things, expensively, while telling themselves they're being prudent.