“Should we build it or buy it?” is the most common AI question founders bring us — and it is the wrong question, because it is not one question. The AI in your product is a stack of layers, and the build-versus-buy answer is different at each one. Treat it as a single decision and you will either reinvent commodity infrastructure or hand your core differentiation to a vendor. Here is the framework we use instead.

Start with the question underneath the question

Before you decide how to source AI capability, decide what role it plays. Is AI the product — the thing customers are paying for, the experience you are judged on — or is it supporting the product, making an existing workflow faster or smoother?

If AI is supporting infrastructure, lean hard toward buying. Speed matters more than control, and there is no prize for a hand-built version of a solved problem. If AI is core to the product, you still buy most of the stack — but you become deliberate about the one or two layers where building is the entire point. This distinction is why companies where search and AI are the product make different calls than companies bolting AI onto an existing offering.

What to buy

For almost every company, the following are buy decisions, and the instinct to build them is a trap:

  • Foundation models. Training one from scratch is a capital-intensive effort only a few companies on earth can justify. You access models through APIs or open weights. This is rented capability, and that is fine.
  • Infrastructure. Vector databases, orchestration, observability, evaluation tooling, GPU capacity. The market is deep and moving fast; your hand-rolled version will be worse and will become a maintenance tax.
  • Commodity capabilities. Transcription, OCR, translation, generic classification. If a dozen vendors offer it, it is not your differentiation.

Buying these is not a compromise. It is what lets you spend your scarce engineering effort on the part that actually matters.

What to own

Build — and own outright — the layers that encode your edge:

  • Your data and the pipelines that feed it. Proprietary, well-governed data is the most durable AI advantage there is. Models are rented; your data is yours.
  • The retrieval and context layer. In most real AI products, quality is determined less by the model and more by what you put in front of it. Your retrieval-augmented generation logic, your ranking, your context assembly — that is product engineering, and it is yours to own.
  • Evaluation. How you measure whether the system is actually good — gold-standard test sets, regression checks, human review loops. Teams that skip this cannot tell improvement from noise. Evaluation is not optional infrastructure; it is how you steer.
  • The integration into your product and workflow. The experience customers touch.

The pattern: rent the engine, own the car.

The lock-in test

Before any AI vendor commitment, run one test. Ask: if this provider doubled its price, degraded its model, or disappeared in eighteen months, what would it cost us to switch?

If the answer is “we re-point an API and re-run our evals,” you have healthy architecture — the model is a swappable dependency behind an interface. If the answer is “we re-architect the product,” you have poured a vendor into your foundation. The fix is not to avoid vendors; it is to isolate them. Abstract the model behind your own interface so the provider stays a dependency you control, never a decision you cannot reverse.

Getting the decision right

Build-versus-buy at the AI layer is an executive decision, because it spans architecture, cost, risk, and product strategy at once. It should not be made by whoever is closest to the code, and it should not be made by the vendor’s sales engineer. It belongs with a CTO or a fractional Chief AI Officer — someone accountable to the business and experienced enough to know which layer is which.

That is much of what we do: sit at the table for these calls before the contracts are signed, while the decisions are still cheap to get right. You can see how those engagements are structured on how we work.

If you are weighing an AI build, a vendor commitment, or a platform decision and want senior judgment before you commit, Book a Discovery Call.

About the author

Grant Ingersoll — Founder, Develomentor

Grant Ingersoll is the founder of Develomentor. He was CTO of the Wikimedia Foundation, co-founded and was CTO of Lucidworks, is a longtime Apache Lucene and Solr committer, and wrote Taming Text. Develomentor delivers fractional technology leadership through a bench of senior practitioners.

AI Build vs. Buy — FAQ

Common questions founders ask when deciding what to build and what to buy at the AI layer.

Should a startup build its own AI models?

Almost never from scratch. Training a foundation model is a capital-intensive effort that a handful of companies in the world can justify. For nearly every startup, the model is something you buy or access through an API. Your advantage is built in the layer above it — your data, your retrieval logic, your evaluation, and your product.

What does AI vendor lock-in actually look like?

Lock-in shows up when switching providers would require re-architecting your product, re-tuning your prompts and retrieval, and re-validating quality from scratch. A healthy architecture isolates the model behind an interface so the provider is a swappable dependency, not a foundation poured into your codebase.

Who should own the AI build-vs-buy decision?

Someone accountable to the business, not the vendor — typically a CTO or a fractional Chief AI Officer. The decision spans architecture, cost, risk, and product strategy, which is why it belongs at the executive level rather than with whoever happens to be closest to the code.

Recognize your situation here?

Tell us what decision is in front of you. We will get back to you within one business day.