The Build vs. Buy Question Is the Wrong Question Now. It's 'Embedded, Point Solution, or Neither.'

For most of my career, “build vs. buy” was a clean enough framing for a software decision. Build it internally with your own engineering resources, or buy a vendor product and configure it. Two options, a familiar tradeoff between control and speed.

That framing doesn’t really describe what’s happening with AI capability in finance orgs right now, and I think a lot of teams are still making decisions using a mental model that’s a version behind reality.

The third option nobody explicitly chose

Most of the AI capability actually being used in finance departments today wasn’t “bought” in the traditional sense at all—it arrived embedded inside tools that were already purchased for other reasons. Your ERP added AI-assisted anomaly flagging in a routine update. Your BI tool added a natural-language query layer. Your productivity suite added a drafting assistant. Nobody ran a vendor selection process for any of this. It just showed up, sometimes turned on by default, sometimes requiring a licensing tier nobody checked before it appeared in a training video.

This matters because it means a meaningful share of your organization’s AI risk and AI capability isn’t sitting in a decision you made—it’s sitting in decisions your existing vendors made on your behalf, and your governance process needs to account for that instead of assuming AI only arrives through a deliberate procurement decision.

Three honest categories, and how to think about each

Embedded (came with a tool you already own). Cheapest to adopt, hardest to govern well, because it often bypasses the scrutiny a new purchase would trigger. The practical move here isn’t to refuse it—refusing usually just pushes people to smuggle it in via personal accounts instead—it’s to actively audit what’s embedded in your existing stack right now, on a real cadence, not assume IT’s official tool list is complete.

Point solution (a dedicated vendor for a specific finance workflow). Best fit when a workflow is specific and high-value enough to justify a standalone tool and its own contract review, its own data-handling due diligence, its own training. The honest cost here isn’t the license fee, it’s the ongoing governance overhead of maintaining a separate relationship, separate data flows, and separate risk review for every point solution you add. Each one is manageable. Ten of them is a program you probably don’t have staffed for.

Build internal (custom, on your own data, for your own workflow). Worth it when the use case is specific enough to your business that no vendor tool fits well (a good example: title-specific spend forecasting in production finance, which off-the-shelf tools generally don’t handle well), and when you have engineering capacity that won’t get deprioritized the moment something more urgent comes up—which, honestly, it usually does, so budget for maintenance, not just the initial build.

What I’d actually do differently starting today

Run an honest embedded-AI audit before your next point-solution vendor pitch. I’d bet most finance leaders reading this could not currently list every AI feature already live inside their existing ERP, BI, and productivity stack, with confidence about what data each one touches. That’s the actual starting inventory, and it’s usually bigger and messier than the “AI tools we’ve adopted” slide in the last board deck suggests.

The build-vs-buy framing assumes you’re making one clean decision. The real 2026 version of this problem is that AI capability is arriving through all three channels simultaneously, mostly without a formal decision at all, and the organizations handling it well are the ones actively looking for where it already is, not just deciding where to add it next.