Build vs. buy is the wrong question for AI features

Almost every client conversation about adding an AI feature starts the same way: "should we build this or use an off-the-shelf API?" It’s a reasonable question, but it assumes the answer is one or the other for the entire feature. In practice, the right answer is almost always a mix — different layers of the same feature have different build-vs-buy calculus, and treating it as one decision leads to either overbuilding undifferentiated infrastructure or under-owning the part that’s actually your competitive advantage.

The foundation model itself — the actual language model doing the reasoning — is the clearest "buy" decision in nearly every case we’ve worked on. Training and maintaining a competitive frontier model is a capital-intensive, ongoing arms race that only a handful of companies in the world are positioned to win. Unless your business is literally building foundation models, renting this layer through an API is the correct call, full stop.

Where it gets more interesting is everything wrapped around that model: the retrieval pipeline that feeds it your specific data, the evaluation harness that catches when it’s wrong, the guardrails that keep it inside your compliance boundaries, the orchestration that decides when to call it versus a simpler deterministic system. That layer is much more often worth owning, because it’s where your actual domain knowledge and competitive differentiation live.

Ask three questions about each layer of the feature, not the feature as a whole. Is this layer something a vendor is already solving well, at a price that scales sensibly with your usage? Is this layer something your competitors could replicate by buying the same vendor product? Is this layer where your actual proprietary value sits — your data, your domain rules, your workflow integration?

Layers that score "yes, yes, no" on those three questions are buy decisions — commodity infrastructure, replicable by competitors, not where your edge lives. Layers that score "no, no, yes" are where you should be spending your engineering time, because that’s the part a vendor can’t sell to your competitor too.

We see two failure modes about equally often. The first is building a custom model evaluation and orchestration layer from scratch when a mature vendor product already solves 90% of the problem — months of engineering time spent reinventing commodity infrastructure. The second is bolting a vendor’s end-to-end "AI feature" product directly onto core workflows with no ownership of the retrieval or guardrail layer, which works fine in the demo and then becomes impossible to debug or customize once a real customer hits an edge case.

The honest version of this advice is that it takes real domain judgment to know which layer is which for your specific feature — there’s no universal answer. But the framework of asking the question per-layer, rather than per-feature, catches most of the expensive mistakes before they happen.

A client came to us wanting "AI-powered search" for a 200,000-document knowledge base, originally scoped as a six-month platform rebuild around a vendor’s end-to-end semantic search product. Running it through the three-question framework changed the shape of the project considerably. The embedding model and vector database: buy, clearly commodity, multiple mature vendors solve this well. The retrieval logic that decides which documents are actually relevant to a given query in their specific domain: build, because their documents had idiosyncratic structure a generic retriever handled poorly. The evaluation harness that catches when search relevance degrades: build, because nobody else has access to what "relevant" means for their specific users.

That reframing turned a six-month platform rebuild into a nine-week additive integration that left their existing platform untouched. The vendor relationship handled the commodity layer at a fraction of the cost of building it themselves; the engineering investment went entirely into the two layers that were actually specific to their business. Search relevance scores in user testing improved substantially, and they shipped in time to matter for a deal they were trying to close — a timeline a full rebuild would have missed entirely.

The lesson generalizes past this specific case: the scoping conversation that matters most happens before any code gets written, when you’re deciding which layers are genuinely yours to build. Getting that wrong in either direction — overbuilding commodity infrastructure or underbuilding your actual differentiation — is far more expensive to fix after the fact than to get right at the start.

Stop asking "build or buy" about the feature as a whole. Ask it about each layer. The answer is almost always some of both, and getting that mix right — owning what’s actually yours, renting what’s genuinely commodity — is a better predictor of whether an AI feature ships on time and stays maintainable than which vendor you picked.