Build vs Buy for AI: A Decision Framework That Survives Contact With Reality

Every AI initiative reaches the meeting where someone says "surely there's a tool for this" and someone else says "we should own this". Both are guessing. Four questions usually settle it.

1. Is this differentiating or operating?

If the capability is how you win deals — the recommendation engine that defines your shopping experience, the underwriting logic that prices your risk — leaning on the same vendor your competitors use caps your upside at parity. Build, or at minimum own the differentiated layer on rented foundations.

If it is operating machinery — transcription, generic support deflection, meeting notes — buy it, integrate it, spend your engineers where customers can tell the difference. Nobody churns because your meeting notes came from a vendor.

2. How deep is the integration, really?

The demo shows the tool alone. Your value comes from the tool wired into the OMS, the catalogue, the policy engine, the human workflows. When integration effort approaches half the build effort, "buy" quietly becomes "build around a vendor" — you carry integration cost and platform risk and renewal leverage sits with them. Price the integration before comparing anything.

3. Does your data give you an edge a vendor cannot have?

Years of labelled support resolutions, structured merchandising outcomes, proprietary catalogue attributes — if your data would make a materially better system and you are allowed to use it, that advantage compounds only in systems you control. If your data is ordinary, a vendor training across a hundred customers may genuinely be better than anything you build. Honesty here saves seven figures.

4. What is the three-year cost, including the boring years?

Buying looks cheap in year one; per-seat AI pricing at scale has a way of tripling. Building looks expensive in year one; then you own an asset with falling unit costs as models get cheaper. Model both at realistic volume with a line for vendor price rises (check their funding stage) and a line for your maintenance (real, but smaller than vendor FUD suggests — modern AI systems are mostly integration code, and integration code is what your team already maintains).

The hybrid that usually wins

Rent the models — training foundation models is nobody's job but a lab's. Own the orchestration: prompts, retrieval, evaluation sets, guardrails, integrations. Buy commodity capabilities at the edge. This keeps switching costs low (swap providers in days, not quarters), keeps your differentiation in code you control, and keeps vendors competing for your inference bill.

We are deliberately on both sides of this — we build custom systems and we implement vendor platforms — which is why clients use us for the decision itself: a two-week assessment with the four questions answered in writing, an architecture, and a recommendation we are willing to be wrong about in public.