title: "The Build vs. Buy Question Nobody Asks" subtitle: "Why the real question is about ownership, not software" type: thinking slug: build-vs-buy status: published featured: false published_at: "2026-01-05"

Every enterprise AI conversation eventually arrives at the build-vs-buy question. The standard analysis weighs development cost against license fees, time-to-market against customization, and engineering capacity against vendor support. These are reasonable factors. They're also the wrong frame.

The question that matters isn't whether to build or buy the software. It's whether to own or rent the capability. Software is an artifact. Capability is the organizational muscle that knows how to use the artifact, adapt it, evolve it, and — crucially — know when it's not working. When you buy a platform, you acquire an artifact. Whether you also acquire the capability depends entirely on how you integrate it, and most organizations don't think about that until it's too late.

The most dangerous AI vendor relationship is the one where the vendor understands your system better than you do.

I've seen this play out with enough regularity to call it a pattern. A company buys a best-in-class AI platform. The vendor's professional services team does the initial integration. The system works well during the honeymoon period. Then requirements change — a new data source, a different use case, a shift in business logic — and the company discovers they can't adapt the system without going back to the vendor. They've acquired software but not capability, and the gap between those two things is where vendor lock-in actually lives.

The build option has its own version of this failure. Companies that build from scratch often over-invest in the initial system and under-invest in the organizational learning that makes the system useful. They end up with a custom solution that's perfectly tailored to yesterday's requirements and expensive to adapt to tomorrow's.

The organizations I admire most have found a third path. They make deliberate decisions about which capabilities are core — meaning they must be owned, understood, and evolvable by internal teams — and which are commodity — meaning they can be rented from vendors without strategic risk. The line between core and commodity isn't static. It shifts as the organization learns, as the market evolves, and as the technology matures. The skill is in knowing where to draw it at any given moment.

For most enterprises, the core capabilities in AI are not model training or infrastructure management. They're data curation, domain-specific evaluation, workflow integration, and feedback loop design. These are the capabilities that determine whether an AI system works in your specific context, and they're the ones that are hardest to buy from a vendor — because they require deep knowledge of your operations that no outside party will ever fully possess.

My advice to clients is usually the same: buy the infrastructure, build the integration, own the feedback loop. The infrastructure is commodity — cloud providers and model APIs will compete on price and performance. The integration layer is where your operational knowledge lives, and the feedback loop is what turns a static system into one that improves. Rent the things that don't differentiate you. Own the things that do.