The build vs. buy question in enterprise software has been debated for forty years. In enterprise AI, it is being asked again as if the answer has not changed - but the dynamics have, and the organizations treating it as the same question they answered about ERP systems in 2005 are making expensive mistakes.
Intact Insurance's CIO of Global Specialty Lines put it plainly in a recent interview: "We don't have to rely on a vendor." The framing is significant. Not "we chose to build rather than buy" - but "we don't have to rely on a vendor" as a statement about strategic positioning. The difference between those two framings is the difference between a project decision and a capability question.
The right question in enterprise AI is not build vs. buy. It is: which parts of our operation are generic enough that a vendor's general-purpose solution will work, and which parts are specific enough that building is the only way to actually solve the problem?
What Vendors Are Selling and What You Are Actually Buying
Every enterprise AI vendor is selling the same thing: a general-purpose capability that works well for the average use case in your category. The average use case is real. Most organizations have many workflows that are close enough to average that a vendor solution works fine.
The problem is not the 80% of workflows where the vendor solution is good enough. The problem is the 20% - the workflows that are specific to how your operation actually runs, the data that is structured the way your systems structured it rather than the way the vendor assumed, the process that reflects twenty years of decisions about how your specific business works.
For that 20%, a vendor solution does not just underperform. It requires your operation to conform to the vendor's assumptions about how the problem should be solved - which means redesigning the process to fit the tool rather than building the tool to fit the process.
The cost of that conformance is invisible until you try to get the tool to do something the vendor did not design it to do. Then it becomes very visible, very quickly.
The Real Cost of the Off-the-Shelf Decision
The immediate cost of a vendor solution is almost always lower than the immediate cost of building. That calculation is real and it matters. But the total cost of ownership calculation - which is the one that determines whether the decision was right - includes costs that do not appear in year one.
The cost of fitting your operation to the vendor's model. The cost of the workarounds your team builds when the vendor solution cannot handle your edge cases. The cost of the integration work when the vendor solution does not connect to your systems the way your systems actually work. The cost of the data migration when you eventually move off the platform. And the cost of the strategic dependency - the negotiating leverage you give up when a vendor's product becomes central to how your operation runs.
7-Eleven's GM of AI, Analytics and Strategy measures AI by the return it creates. He also noted something more fundamental: knowing when data is not the answer is as important as knowing when it is. The same principle applies to vendor solutions. Knowing when a vendor solution is not the answer - when the workflow is specific enough that general-purpose does not fit - is as important as knowing when to buy.
When to Build and When to Buy
The framework is simpler than the debate suggests.
- Buy when: The workflow is generic. The vendor's model of how the problem should be solved is close enough to how your operation works that the conformance cost is low. The problem is well-understood and the vendor has already solved it well. The data requirements are standard and your data is clean enough to meet them.
- Build when: The workflow is specific to your operation. The problem requires understanding how your business actually runs before knowing how to solve it. The data is structured in ways that reflect your systems and your history rather than a vendor's assumptions. The outcome matters enough that approximating it is not acceptable. The competitive advantage comes from solving the problem better than the vendor solution allows.
- Build when the vendor does not know your problem. This is the most reliable signal. When you are explaining your specific use case to a vendor and they keep mapping it back to their general model rather than engaging with the specifics, they have told you that their solution was not designed for your problem.
The AI Dimension
The build vs. buy question in AI has an additional dimension that does not exist in traditional software: the intelligence in the system depends on understanding the context it operates in.
A general-purpose AI tool operates on the data it is given and the context embedded in its training. It does not know how your operation works. It does not know the specific patterns in your data. It does not know the compliance requirements of your specific industry in your specific jurisdiction. It does not know the edge cases that matter most in your specific workflow.
A purpose-built AI system is designed around all of those things. It is trained or configured on your data. It is designed for your workflow. Its output is calibrated for your use case. The intelligence is specific to your operation rather than averaged across everyone who uses the vendor's platform.
That specificity is not just a feature. It is the difference between an AI system that actually changes how your operation works and one that helps individual users be slightly more productive without changing anything at the organizational level.
The Honest Answer
The honest answer to build vs. buy in enterprise AI is that most enterprise AI investments should be a combination of both - vendor solutions for the generic workflows and purpose-built systems for the specific ones. The mistake is applying vendor solutions to specific problems because the immediate cost is lower, and then spending the next three years managing the gap between what the vendor solution does and what your specific problem actually requires.
Intact Insurance's "we don't have to rely on a vendor" is not an argument against vendor solutions. It is an argument for knowing which problems are yours to solve and building the capability to solve them - rather than accepting that every problem in your operation has a vendor solution that is good enough.
The Bottom Line
Build vs. buy is the wrong question. The right question is: which of our specific problems are specific enough that a vendor cannot solve them, and what would it take to build what is actually necessary?
The organizations that have answered that question honestly are the ones with AI systems that have changed how they operate. The organizations still debating build vs. buy at the category level are the ones with vendor solutions that work for 80% of the use case and workarounds for the rest.
Anterra builds what is actually necessary for your specific operation - starting with the problem, not the product catalog. If you have a workflow that no vendor has built the right solution for, that is exactly the conversation we are set up to have.