Build vs. Buy vs. Deploy: Using a Decision Tree to Select the Right Enterprise AI Path

A manufacturing CIO brought two estimates to discuss last month. One came from his team: two years, six engineers, and a Q&A system built internally from scratch. The other was from a global SaaS vendor, annual subscription, deployable within a week. He wanted to know which path made sense.

My answer: "Neither might be right."

"Build or Buy AI" Is Asking the Wrong Question

The question dominates every boardroom, but it presents a false binary and ignores a third option entirely. The first path is building in-house: you hire staff, run the system, and retain ownership of the models and data. The second is purchasing SaaS: monthly fees, user seats, and features the vendor has already defined. The third path, only recently possible at scale, is on-site deployment: engineers arrive, work within your infrastructure and processes, assemble open-source or commercial models into a system tailored to your company, and remain involved until actual users depend on it.

None of these paths is inherently superior. The right choice depends on fit. Fit isn't determined by budget size or executive enthusiasm for AI. It comes down to three concrete factors: data sensitivity, edge-case density, and in-house operations capability.

Data sensitivity asks whether your most critical information can leave your infrastructure. Patient records. Credit-decision models. Unreleased financial statements. Production-line quality metrics. Once this information flows to a third-party cloud, you lose both compliance control and negotiating leverage. For organizations with high data sensitivity, the SaaS path is essentially closed.

Edge-case density asks how much your business deviates from standard operations. The manufacturing customer's 4 percent adoption rate was a symptom of this problem. SaaS platforms are built for typical customers. The more exceptions you encounter, custom pricing logic, multi-step approvals, rules only long-serving employees understand, the wider the gap between what a product offers and what you actually need. This gap is where adoption fails.

In-house operations capability asks who maintains the system after launch. Models degrade. Data schemas change. Users submit queries you never anticipated. Building in-house requires a permanent team capable of refining prompts, re-embedding data, and interpreting logs. Without that team, any homegrown system begins to deteriorate the moment your lead engineer leaves.

Mapping All Three Paths on One Decision Tree

This framework appears on the whiteboards of our client meetings regularly. Score yourself across all three dimensions, then locate your cell.

One cell receives the least attention: high data sensitivity, high edge-case density, weak in-house operations. Companies landing here face the greatest difficulty. Compliance eliminates the SaaS option. Headcount constraints eliminate the build option. The result is delay or purchasing a system that produces the same 4 percent adoption story. On-site deployment exists for this specific cell, not to sell a product, but to station engineers within your environment to build the system from your data and train your team to eventually assume support responsibilities.

The Real Costs Never Show Up on Price Quotes

Price quotes list licensing fees and labor hours. What they omit is where actual spending occurs afterward.

The hidden cost of SaaS is modifying your business to fit the tool: you restructure your own processes to work with the vendor's product, and staff find it burdensome enough to simply stop using it. The hidden cost of building is the operations burden that follows: the first version ships in three months and performs well. The next three years of drift, updates, and on-call rotations consume the majority of total spending, yet almost no one budgets for this at project approval.

On-site deployment has its own trade-offs. Upfront costs exceed SaaS, and timelines extend beyond building, because engineers need time to understand your business, work with imperfect data, and absorb the unwritten operational rules. This ramp period cannot be avoided. The payoff emerges later: the system grows with your actual needs, deployment happens with real usage from day one, and the knowledge stays within your team.

This CIO's situation: data sensitivity was high (credit decisions and customer financials), edge-case density was high (each production line followed different rules), and in-house operations capability was medium (functional IT department, no ML expertise). According to the decision tree, both estimates fell into the wrong cell.

Figure Out Your Cell Before You Start Negotiating Price

Most AI implementations fail not because the vendor selected was wrong, but because nobody mapped their own three dimensions before comparing prices. Price comparison should be the final step, not the first.

Every Tenten project starts by sitting with the client to plot these three dimensions and walk through the decision tree. Sometimes we reach the conclusion and recommend they purchase SaaS, because that is the right fit. The organizations that need on-site deployment are those where data cannot leave the building, exceptions exceed what any product covers, and a capable in-house operations team doesn't yet exist. The decision tree prevents signing quickly and launching into chaos.