The Build vs Buy Decision for AI
Three rules and a default. Most companies build too much and buy too little.
TL;DR
Three rules:
- Buy commodity capabilities — customer support, document understanding, generic content generation. The market has good products; building costs more for less.
- Build differentiating capabilities — capabilities that change your unit economics or product position. The work is hard but the moat is real.
- Don’t outsource the agent that defines your product — even if a vendor can build it. Strategic AI capabilities should sit in-house.
The default for most enterprises in 2026: buy 70%, build 30%. The reverse is the default failure mode.
Three rules and a default. Most companies build too much and buy too little.
The “build vs buy” question for AI gets the wrong default at most companies. Engineering teams want to build (interesting work, perceived control); the result is too much engineering invested in capabilities that vendors do better, and too little engineering invested in the strategic capabilities that need to sit in-house. This piece is the decision frame and the default.
The three rules
Rule 1: Buy commodity
For capabilities that are increasingly commoditized, buy. Examples:
Customer support agents. Intercom Fin, Decagon, Sierra, others. The market has $5M+ ARR products with high deflection rates and good operations.
Document understanding. Specialized vendors with strong models for invoice processing, contract analysis, claims documents.
Generic content generation. Marketing copy, basic translations, summarization. The vendor market is competitive.
Sales productivity. Outreach automation, call summarization, CRM enrichment. Many strong products.
For these, buying gets you to value faster, with better total economics, and with vendor accountability for ongoing model improvement. Building means re-creating capabilities that already exist.
The trap: engineering teams underestimate the gap between “we built a working prototype” and “we built a production-grade product.” For commodity capabilities, vendor products are 12–24 months of work ahead of internal builds.
Rule 2: Build differentiating
For capabilities that change your unit economics or product position, build. Examples:
An AI capability inside your product that customers value and competitors don’t have. The product team owns this; vendor solutions are not differentiating by definition.
A workflow specific to your business that doesn’t have an off-the-shelf solution. Often the highest-value AI work in an enterprise.
A capability you sell as part of your product. AI features that are part of your value prop should be built so you control the roadmap, the data, and the differentiation.
Building here is harder than buying — but the moat is real and the value created is yours.
Rule 3: Don’t outsource what defines you
Even when a vendor can build a capability for you, capabilities that define your product or business should sit in-house. Examples:
A specialized agent that’s core to your offer. If your B2B SaaS has an “AI assistant” feature that customers buy you for, that assistant should be built and owned by your team.
The data flywheel that powers your moat. Customer data + AI behavior + iteration. This loop should be in-house; vendoring it gives away the flywheel.
The judgment your business is built on. A consulting firm’s analytical agents; a financial advisor’s research agents; a hospital’s clinical decision support — these embody the firm’s judgment and shouldn’t sit at a vendor.
The vendor model is fine for capability; not for identity.
The 70/30 default
For a typical mid-large enterprise in 2026:
- ~70% of AI investment goes to bought capabilities (vendor products, platforms, foundation models).
- ~30% goes to in-house engineering on differentiating capabilities.
Most enterprises currently invert this — too much building, too little buying. The transition takes 12–24 months as engineering capacity gets reallocated.
When to switch from build to buy (and vice versa)
Build → Buy: when the vendor market for the capability matures and your built version is now more expensive to maintain than vendor cost. Common 18 months after a wave of vendor entry. Migrate; don’t keep maintaining.
Buy → Build: when the bought capability becomes strategic (you’re growing into it as a product line) or when the vendor’s roadmap diverges from yours. Less common but important.
Both transitions are work; budget for them.
What to do this quarter
- Inventory your AI investments. What’s built vs. bought today?
- Apply the three rules. Each investment should pass: are we building commodity (wrong)? Are we buying differentiation (also wrong)?
- Plan the rebalance. Most enterprises need to shift toward more buy. The shift is 12–24 months of work.
- Identify the 1–3 capabilities that should be built but aren’t. These are usually the strategic gaps.
Counter: build is cheaper than vendor licenses?
Sometimes. The cost comparison should include:
- Vendor license cost over 3 years.
- Internal engineering cost: build + ongoing maintenance + governance + supervision.
- Risk-adjusted: cost of vendor failure vs. cost of internal failure.
- Opportunity cost: what else would the engineering team do?
For commodity capabilities, vendor cost is usually lower on a 3-year basis. For differentiating capabilities, internal cost can be lower because the alternative isn’t “vendor cheap” — it’s “no good vendor exists.”
How vendor selection has changed
Three notes on AI vendor evaluation specifically.
1. Model neutrality matters. Vendors locked to one foundation model are at risk if model dynamics change. Prefer vendors that support multiple foundation models or have abstracted the model layer.
2. Data isolation is non-negotiable. Your data should not train vendor models. Get this in the contract; verify in security review.
3. Roadmap alignment matters more than feature parity. AI vendor capabilities change every quarter. Pick vendors whose roadmap aligns with where you need to go, not vendors with the best feature set today.
FAQ
What about open-source AI? Open-source as a third path: own the code, host the models, customize freely. The right answer when you need control without vendor dependency. The cost is engineering capacity to operate; the benefit is no vendor lock-in.
Should we use foundation models directly or via vendors? Both. Direct API for in-house builds; vendor products for bought capabilities. The “build everything on raw OpenAI/Anthropic API” pattern under-leverages the vendor market.
What about consulting firms building bespoke AI? Treat as buy with extra coordination cost. Useful when you don’t have internal capacity but want a custom build. Make sure the IP terms and operating model are clear; many firms keep the IP, which negates the build argument.
How does this change for regulated industries? Buy options are narrower in regulated industries (specialized vendors with compliance posture). Often you build because the buy market is shallow. Plan for higher in-house investment in regulated contexts.
What’s the right mix for a small/mid-size company? More buy, less build. Smaller companies should rarely build — engineering capacity is too constrained. 90/10 buy/build is reasonable; the 10% goes to the 1–2 capabilities that genuinely differentiate.
Working with JAIN on AI build vs. buy? We help executive teams apply the three rules and rebalance their portfolios. Book a 30-minute call.
Related reading:
Want to talk through this for your team?
30 minutes, no slides. We'll work the specific call your company is facing.