Build vs Buy for AI Inside an ERP

A CFO asked us whether he should buy an AI layer for his ERP or have someone build one custom, and then asked the question again five minutes later once he realized his first answer to himself had been based entirely on what a vendor pitched him last month rather than what his company actually needed.

That is the normal starting point for this decision. Most companies form an opinion from whoever pitched them most recently, not from a clear read of their own situation.

Buy when the problem is common across companies. Build when the problem is specific to how you operate.

The clearest signal for buying is that the underlying problem is largely the same from company to company: invoice matching, standard financial reporting, common inventory forecasting patterns. Vendors solving common problems can spread their development cost across many customers, which usually makes buying both faster and cheaper than building the same thing yourself.

The clearest signal for building is the opposite: a workflow specific enough to your operation that no vendor has solved it well, because the market for that exact problem is too small to justify their investment. Custom manufacturing sequencing tied to your specific equipment, or a pricing model shaped by years of unique customer agreements, tend to fall here.

Most companies get this decision backwards, building what they should have bought and buying what they should have built.

Companies with strong internal engineering teams sometimes default to building everything, including problems a vendor already solved well, because building feels more in control and internal teams enjoy building. That instinct burns real budget reinventing something a subscription would have handled at a fraction of the cost.

The opposite mistake is just as common. Companies buy a generic AI platform and then spend a year trying to force it to handle a workflow specific enough that no off the shelf product was ever going to fit, because buying felt faster at the start even though it was never actually going to be faster in total.

ERP data specificity is usually the deciding factor, more than the AI capability itself.

The AI models underlying most vendor products today are broadly similar in raw capability. What actually differs between a good fit and a bad one is how well the surrounding implementation understands your specific ERP configuration, your custom fields, and the workflow quirks unique to your operation.

A vendor selling a generic AI layer for a common ERP platform can genuinely work well if your configuration is close to standard. If your ERP has been heavily customized over a decade, that same generic layer usually needs custom work regardless of whether you call the overall project a buy or a build.

A hybrid approach is often the honest answer, even though it is less satisfying than picking a clean side.

Buy the foundational AI capability from a vendor who has already solved the hard, common part of the problem well. Build the specific connective layer that adapts that capability to your particular ERP configuration and workflow. This is closer to what forward deployed engineering actually is: neither a pure product purchase nor a from scratch build, but the deliberate work of fitting a general capability to a specific environment.

Framing the decision as strictly buy or strictly build often produces a worse outcome than accepting that most real implementations need pieces of both.

Total cost of ownership matters more than the sticker price on either side of this decision.

A build looks expensive upfront and a subscription looks cheap upfront, which is exactly the comparison that leads companies astray. The real comparison has to include ongoing maintenance, the cost of keeping a build current as your ERP changes, and the cost of a vendor subscription that never quite fits and requires workarounds every quarter.

Companies that run this comparison honestly, over three years rather than one, frequently reach a different conclusion than the one that looked obvious in the first meeting.

Vendor lock in deserves more weight in this decision than most companies give it upfront.

A purchased AI capability that becomes deeply embedded in daily operations creates real dependency on that vendor's roadmap, pricing changes, and continued existence as a company. This is not a reason to avoid buying, but it is a real cost that rarely gets modeled honestly during the initial decision, when the vendor relationship still feels easy to walk away from if needed.

A build carries the opposite risk: dependency on whichever internal team or contractor built it, and on that knowledge staying documented and current after the original builder moves on. Neither path escapes dependency entirely. The question is which kind of dependency your company is actually better positioned to manage.

The wrong choice here is expensive in a way that is hard to reverse quickly.

A poorly chosen build becomes a maintenance burden that quietly consumes engineering time for years. A poorly chosen buy becomes a subscription the company keeps paying for a capability nobody actually uses, because switching costs and sunk cost thinking make it easier to keep paying than to admit the fit was wrong.

What CEOs ask us about this

How do we know if our ERP is customized enough to require building?
If a standard vendor demo would need significant modification just to reflect how your ERP is actually configured, that is a strong signal toward building or heavily customizing rather than buying as is.

Is building always more expensive than buying?
Not necessarily, once you account for years of subscription costs and workaround maintenance on a poorly fitting purchased tool. The real comparison requires a multi year total cost view, not a first year price comparison.

Can we start with buy and switch to build later if needed?
Yes, and this is often the lower risk path, since it lets you learn exactly where the generic product fails before committing engineering resources to solve that specific gap.

Who should make this decision, IT or the business unit that will use it?
Both, together. IT understands the technical fit and long term maintenance burden. The business unit understands whether the workflow gap is actually specific enough to justify a custom build.