Build vs buy AI: buy the generic, build the differentiating
The build vs buy question for AI has a one-sentence answer that has held up across every engagement we have run: buy the capabilities that are generic to every company, build the ones that encode how your company makes money. The principle is easy. The hard part is being honest about which of your use cases are differentiating, and about the hidden costs on both sides of the ledger.
What follows is the framework in full, the current data on how each path performs, and the hybrid that most mid-size companies should be running.
Buy the generic, build the differentiating
Some capabilities look identical in every company that deploys them. Meeting transcription, email drafting, document search, coding assistance. A vendor amortizes development across thousands of customers, iterates faster than you ever will, and prices the result below what an internal build would cost to maintain. Buying these is procurement rather than strategy, and you should treat it like procurement: compare, negotiate, keep switching costs low.
Then there are the workflows that exist nowhere else. The way your underwriters price risk. The claims process your ops team refined over a decade. The margin logic buried in your quoting spreadsheet. No vendor sells a product that fits these, because if a product fit them, they would be generic.
The test we use with clients: imagine your closest competitor deploys the exact same tool tomorrow morning. If nothing about your relative position changes, buy it. If the workflow embeds judgment, data, or process that took years to accumulate, that is build territory.
What the data says about buy vs build
MIT’s Project NANDA published its State of AI in Business 2025 report with one finding everyone quoted: about 95 percent of enterprise GenAI pilots produced no measurable P&L impact. The less quoted finding is more useful for this decision. Tools purchased from specialized vendors reached successful deployment roughly two thirds of the time, while internally built systems succeeded about a third as often. The sample was small, so treat the ratio as a direction rather than a law, but the direction is clear.
Read that carefully before concluding you should never build. The failed internal builds in that sample were largely generic use cases, assistants and summarizers assembled by teams without production AI experience. Those were the projects that should have been purchases. Building a differentiated workflow with people who have shipped AI systems before is a different exercise, and the discipline gap, more than the ambition, is what kills most of them. We unpacked that in why most AI projects die.
The hidden costs of buying
Per-seat pricing looks harmless at 20 users and becomes a board-level line item at 2,000. Integration work rarely appears on the vendor’s pricing page but always appears on your invoice. And there is the workflow gap: the tool covers 70 percent of your process, and the missing 30 percent is usually where the value sat, because the missing part is the part specific to you.
The subtler cost is strategic. Your data accumulates inside someone else’s product, on someone else’s roadmap. When the vendor raises prices, pivots, or gets acquired, your process moves with them. And off-the-shelf assistants tend to raise individual productivity, then stall at the boundary of your systems. We described that plateau in ChatGPT Enterprise is not an AI strategy.
Buying is still often the right call. The real price is just higher than the subscription number, which matters when you compare it to a build.
The hidden costs of building
The symmetric mistake is treating the build cost as the whole cost. The build is the entry fee; what you take on is ownership of a living system. Models improve and get deprecated. Evaluation sets need maintenance as the workflow evolves. Someone has to watch quality, cost per request, and drift, and be accountable when the system degrades quietly. If you are not prepared to fund that ongoing ownership, do not start the build.
The other classic failure is scope. Companies that decide to build often decide to build a platform, an eighteen-month program with a steering committee. Custom AI earns its keep when it is narrow and deep: one workflow, one metric, production in months. For what the numbers look like by system type, see what custom AI development costs.
The hybrid most companies should run
In practice the answer is usually a portfolio. Buy the horizontal layer, an assistant subscription for everyone, and let it harvest the easy productivity gains. Then pick one or two workflows where AI touches your margin or your customer experience directly, and build those properly: prototype on your real data in 2 to 4 weeks, measure against a baseline, kill it without ceremony if the metric does not move. Choosing that first workflow well matters more than the technology, and we wrote a separate note on choosing your first AI use case.
The sequencing matters too. The bought layer teaches your teams what the technology can do. The built layer is where the competitive result lives. Companies that only buy get the same AI as everyone else, by definition.
If you have a workflow you suspect is build territory and want a second opinion on whether it justifies a build, that scoping conversation is how our custom AI work usually starts.