Build vs. buy is the wrong question for AI

Every enterprise having the AI conversation eventually lands on the same question. Do we build or buy? And I think it's the wrong question, not because the answer doesn't matter, but because the framing misses what actually determines success.

In my experience, external partnerships succeed roughly twice as often as internal builds for enterprise AI. And it's not because vendors are smarter. It's because the partnership structure solves problems that have nothing to do with technology.

The instinct to build internally is understandable. You control the stack, you own the IP, you keep your data in-house. And you have smart engineers who are excited about AI. All of these are real advantages. None of them are the problem.

Internal AI builds fail because they run into organizational fragmentation without an external party to break the deadlock. When data ownership sits with one team, infrastructure with another, the workflow with a third, and compliance with a fourth, every design decision becomes a negotiation. There's no one who can say "this is how it needs to work" and have the credibility to make it stick.

I've watched this play out repeatedly. An internal AI team spends months building something technically impressive. But they can't get the data team to prioritize the integration they need. They can't get compliance to sign off on the governance model. They can't get the business unit to change their workflow. Each of these is a reasonable request being made to a team with different priorities. And without someone external whose entire business depends on the deployment succeeding, these deadlocks don't resolve. They just persist until someone declares the pilot "successful" and moves on to the next initiative.

I've noticed mid-market companies tend to move from pilot to production in about 90 days. Large enterprises take nine months or longer. The internal build path magnifies this gap because it adds engineering scope to an already slow organizational process.

The best AI vendor relationships I've seen looked nothing like traditional software purchases. They were closer to co-development arrangements. The vendor brought domain expertise and a system capable of learning. The buyer brought workflow knowledge and data. Both sides iterated together.

The buyers who succeeded treated AI vendors less like software providers and more like business service partners. Closer to how you'd work with a consulting firm or a BPO. They demanded deep customization aligned to their specific processes, benchmarked on operational outcomes rather than model benchmarks, and partnered through early failures instead of walking away after the first miss.

That's a fundamentally different posture than traditional enterprise software procurement. You're not evaluating features against a requirements doc. You're co-designing how intelligence gets embedded into operations. And that co-design process, I think, is what drives the difference in outcomes. Not because external teams are smarter, but because the partnership structure creates accountability and forcing functions that internal builds lack.

Build vs. buy frames AI as a procurement decision. The better frame is: how does your organization learn?

The gap between internal and external success rates isn't really about who builds the technology. It's about learning speed. External partnerships compress the learning cycle for several reasons. The vendor has already failed at this before, so they bring pattern recognition that an internal team building for the first time simply doesn't have. External teams break organizational deadlocks because they bring credibility that internal teams often lack. And vendor incentives are aligned with deployment in a way that internal team incentives sometimes aren't. An internal team can exist in pilot mode indefinitely. A vendor who doesn't get to production doesn't get renewed.

Counter-intuitively, customization often happens faster with external partners too. The vendor brings a starting point. Internal teams start from zero.

If I were an enterprise leader deciding how to approach AI, I'd stop treating it as a build/buy binary. The highest-performing organizations I've worked with use hybrid approaches, with internal teams working alongside external partners and clear ownership of outcomes.

I'd evaluate vendors on learning capability rather than feature lists. Most executives I talk to want tools that improve over time and retain context. But most RFP processes don't test for this. If a vendor demo doesn't show how the system gets smarter with use, that tells you something important about their architecture.

I'd give budget authority to frontline managers rather than central labs. The best deployments I've seen started with power users who already used ChatGPT and understood what AI could do. Central AI labs tend to build what's technically interesting. Frontline managers build what's operationally useful. These are different things, and the second one is what actually matters.

And I'd set a 90-day deployment target. Not because speed is inherently good, but because speed is how you learn whether something works before organizational inertia kills it.

Most internal AI builds, I think, are a way of avoiding the harder organizational work. Building gives you the feeling of progress (sprints, demos, architecture reviews) without forcing the organizational changes that actual deployment requires. For most enterprises, the fastest path to production AI is to find a partner who's already solved the technical problem and focus your energy on the organizational one. Less exciting than building your own models. Also more likely to work.