Why the old rules give the wrong answers
For 15 years the build-vs-buy heuristic in software was clean: buy commodity, build differentiator. CRM was a buy. Authentication was a buy. Anything central to your competitive moat was a build. The framework worked because the cost curves were stable, the integrations were boring, and the SaaS market was mature enough that a “buy” decision was usually safe.
AI breaks every part of that framework.
The cost curves are not stable — token prices drop 50% a year, capabilities shift quarterly. The integrations are not boring — they’re the whole product, and they require deep access to your data and workflows. The vendor market is not mature; most AI vendors will not exist in two years, and the ones that do will look completely different from what you bought today.
The result is that companies applying SaaS-era build-vs-buy logic to AI are making category errors in both directions: buying capabilities they should have built, and building capabilities they should have bought. The framework below is the one we use in our practice.
The five questions that actually decide
There are five questions. Answer them honestly and the build-vs-buy call usually becomes obvious.
1. Is the capability the product, or adjacent to it?
If the AI capability is core to your product — the thing customers pay you to do — you build the orchestration even if you buy the model. If the capability is adjacent (internal productivity, back-office automation), you can buy or build with much less consequence.
The error here is that companies treat “adjacent” as “buy.” Sometimes the cheapest adjacent build is shockingly fast, especially with frontier models doing the heavy lifting. We’ve shipped internal tools in two weeks that the SaaS quotes for were $80k/year. Adjacent doesn’t automatically mean buy.
2. What’s the contract exit cost?
The first question to ask any AI vendor: how do we leave you cleanly? Most AI vendors have an answer that is either evasive or terrible. Data is embedded in their indices, their fine-tunes, their workflow definitions. The export is partial. The IP boundary is murky. The migration path is “rebuild from scratch.”
If the exit cost is high, the buy decision is much worse than it looks. We treat exit cost as a multiplier on the apparent vendor price; a 3x exit-cost vendor is effectively priced at 3x their list rate in expected value terms.
3. How fast is the capability frontier moving?
The faster the capability frontier moves, the worse “buy” looks. SaaS vendors update their products on a quarterly or annual cycle. AI capabilities move monthly, and the floor under the frontier moves with them — what was state-of-the-art six months ago is now a self-hostable open model.
If you buy a vendor today for capability X, you are betting that the vendor’s product will keep pace with the open frontier for the life of the contract. Most vendors won’t. Many will get worse by comparison even if their absolute capability improves, because the frontier moves faster.
For fast-moving capabilities, building thin (a thin orchestration over swappable models) often beats buying. The build inherits frontier improvements for free; the buy doesn’t.
4. What’s the data sensitivity?
If the workflow involves sensitive data — PII, PHI, financial detail, regulated data — the vendor question is more expensive. You need DPAs, you need data-residency commitments, you need audit rights, you need indemnification. Some vendors won’t give you those terms at any price. Others will, but only in their enterprise tier at 5x the price.
For high-sensitivity workflows, build is often safer than buy, because building keeps the data inside your boundary by default.
5. What’s the team capacity to operate it?
This is the question companies under-weight most often. Building AI is one thing. Operating it — monitoring, debugging, evolving — is the harder job. If you don’t have an engineering team that can keep an AI system healthy in production, you should not build no matter how attractive the math looks. Operating ten internal AI systems requires more capacity than building them; teams that are excited to build are usually surprised by the operational cost.
For teams without operational capacity, buying is correct even when the build math looks better, because the build will rot.
The decision matrix
Combine the five answers like this:
- Core to product + fast frontier + high data sensitivity → build. No question. Anything else creates strategic exposure.
- Adjacent + slow frontier + low sensitivity + thin team → buy. Easy call.
- Core + slow frontier + low sensitivity → buy, with strong exit terms. Negotiate the contract well; revisit annually.
- Adjacent + fast frontier + decent team → build thin. The frontier improvements compound; the build cost is low.
- High data sensitivity + thin team → fractional support to build, then operate yourselves. This is exactly the gap that our practice often fills.
Three specific cases where companies get it backwards
The pattern errors we see most often:
Case 1: Buying a chatbot vendor for customer support. Every team thinks this is a buy. Often it’s a build. The capability is core (customer-facing), the frontier is moving fast (chat agents improve monthly), the data is sensitive (customer accounts). Vendors charge $80–250k a year and lock you in. A thin custom build on frontier models with a CAIO-shaped operating plan often costs less to build than one year of vendor cost and gives you full control of the experience.
Case 2: Building an internal knowledge agent from scratch. Every team thinks this is a build. Often it’s a buy. The capability is adjacent (internal productivity), the frontier is moving fast (so vendor and build both improve), and the data sensitivity is medium. The right call is usually to buy an internal-facing agent (Glean, Notion, etc.) and accept that you’ll switch in two years.
Case 3: Buying a “platform” for everything. Some vendors are selling AI platforms that promise to be the one tool for everything. These are almost always a bad buy in 2026, because no platform can keep pace with the frontier across every dimension. The platforms that survive will become commodity routing layers — pay for routing, not for “the AI platform.”
How the build-thin pattern works
The pattern we use most often for “build” decisions is build thin:
- Use frontier models via API (don’t fine-tune unless you have a clear reason).
- Wrap them in a thin orchestration layer (often WAT-shaped).
- Use MCP for tools, so the tools survive provider changes.
- Centralize credentials in a gateway, so providers are swappable.
- Keep the build small: 2–3 engineers, 8–12 weeks for a meaningful capability.
The build-thin total cost for a meaningful capability is typically $80–250k all-in, similar to one year of vendor cost, with no recurring license fee, full control, and frontier-improvement upside. For mid-market companies with even modest engineering capacity, build-thin wins more often than the conventional wisdom suggests.
The take
The 2026 build-vs-buy decision is not about whether you can build. It’s about whether the frontier is moving faster than vendors can keep up with, whether your data sensitivity allows for vendor relationships at all, and whether your team can operate what you build. Five questions, answered honestly, give you the answer. Skip the questions and you’ll buy what you should build or build what you should buy — both of which are expensive lessons.
Build-vs-buy is one of the questions an AI Readiness Audit answers, and “build thin” is the default pattern in our Custom AI Builds. Schedule a call if you want a second opinion on a specific decision.
