Build vs Buy AI: The Executive's Decision Framework

6 min read · Updated 2026-05-02

Runrate Framework

AI Workforce P&L

Treat AI agents like employees: cost structure, productivity target, and retirement trigger per agent.

Read the full framework →

Every AI leader asks the same question: "Should we build our own AI system or buy from a vendor?" The answer is: it depends. But "depends on what" is the wrong frame. The right frame is: "What does our organization do best, and what are we renting?"

Treat AI like payroll. You don't build your own payroll system (unless you're ADP); you buy from Workday or Gusto because that's not your competitive advantage. Conversely, you do build your customer data model because that's proprietary to your business and a source of leverage. The same logic applies to AI.

The seven questions that determine build vs buy

Use these questions to decide. If you answer "yes" to more than four, you probably should build. If you answer "yes" to fewer than three, you should buy.

Question 1: Is this your core business model?

If the AI agent is the thing your customer pays for, you might need to build. A financial services firm selling AI-powered underwriting needs to own the model. A healthcare company selling an AI-powered claims adjudication engine needs to own the logic.

If the AI agent is internal tooling that supports your business but isn't the product, you should buy. A bank using AI for internal document processing should buy. A hospital using AI for scheduling should buy.

The reason: if your customer is paying for your AI, they'll eventually expect customization, model updates, and integration depth that only you can provide. If it's internal, a vendor will do.

Question 2: Do you have a dedicated ML team?

Building AI requires ML engineers, data engineers, prompt engineers, and continuous monitoring. This is a 5–10 person team at minimum for a non-trivial agent.

If you have in-house ML talent and they have capacity, building becomes feasible. If you're planning to hire ML team members to build AI, stop. The hiring cycle alone will add 6 months, and your ML budget might be better spent on tooling and evaluation.

Most enterprises should buy.

Question 3: Is speed to deployment more important than ownership?

If you need to deploy an AI agent in 6 weeks, buy. If you have 6 months, building becomes viable.

Buying gets you to production in 4–8 weeks. Building takes 3–6 months, plus 2–4 months of evaluation, plus 2–3 months of tuning. Buy if speed matters. Build if you have time and want to control the full lifecycle.

Question 4: Can you control the work item definition?

The narrower and more standardized your work item, the easier it is to buy. A vendor's agent is built for the "80% case." If your work item is the 80% case (password resets, simple claims, standard underwriting), buy. If it's the 20% case (complex exceptions, highly customized logic, proprietary data), build.

Test this: Can you write a specification for the work item in 50 words? "We want to resolve password reset and billing inquiry tickets for English-speaking customers with a 72-hour SLA." That's buyable. "We want to adjudicate insurance claims that involve unusual coverage combinations, state-specific regulations, and require probabilistic reasoning about ambiguous policy language." That's buildable.

Question 5: Do you have proprietary training data?

If your competitive advantage is proprietary training data (customer history, domain-specific judgments, proprietary knowledge base), you might need to build so you can use that data to fine-tune or train a custom model.

If your training data is generic or openly available, buying is fine. You can use the vendor's pre-trained model.

Question 6: What's your true cost?

Build a cost model for both scenarios. Building typically costs $500K–$2M in year 1 (team, compute, tooling) and $300K–$800K annually thereafter. Buying typically costs $50K–$500K annually depending on volume.

A worked example:

Scenario: AI for customer support at a mid-market SaaS company

Buy scenario:

  • Vendor cost: $3,000/month base + $0.50 per resolved ticket
  • Volume: 5,000 tickets/month
  • Monthly cost: $3,000 + (5,000 × $0.50) = $5,500/month = $66,000/year
  • 1-year cost: $66,000
  • 3-year cost: $198,000

Build scenario:

  • ML team (2 FTE): $300K/year
  • Infrastructure (compute, vector DB, observability): $50K/year
  • Training and ongoing improvements: $50K/year
  • Vendor inference (run on Claude or GPT): $30K/year
  • Total year 1: $430K
  • Year 2–3: $150K/year (assumes team is hired)
  • 3-year cost: $730,000

In this scenario, buying is 3.7x cheaper over 3 years. You'd need to justify building on strategic grounds (differentiation, custom capabilities, vendor risk), not on cost.

Question 7: What's your risk of vendor lock-in?

If you're buying from a vendor with high lock-in risk (proprietary model, no data export, high switching cost), you should ask whether building gives you independence.

But building creates a different lock-in: you're locked in to your ML team and your infrastructure choices. A better frame is: which lock-in can you tolerate? Most companies tolerate vendor lock-in more easily than they tolerate team dependency.

Buying from a vendor with strong data export rights, model agnosticism (can swap Claude for GPT), and a reasonable switching cost (4–8 weeks) is actually lower risk than building.

The worked example: AI customer support

Let's walk through all seven questions for a mid-market SaaS company with 5,000 support tickets per month.

Q1: Core business model? No. Support is a cost center, not a revenue driver. → Leans buy.

Q2: Do you have an ML team? No. You have three engineers, all focused on the product. → Leans buy.

Q3: Speed to deployment? Need to deploy in 8 weeks. → Leans buy (vendor = 6 weeks, build = 18 weeks).

Q4: Can you control the work item? Yes. You can define "password resets, billing inquiries, and basic account issues" as the buyable 80%. → Leans buy.

Q5: Proprietary training data? No. Your support data is generic SaaS support data. → Leans buy.

Q6: True cost? Buy is $66K/year. Build is $430K year 1. ROI breakeven is 6.5 years (unlikely). → Strongly leans buy.

Q7: Vendor lock-in? If you choose a vendor with good data export and model agnosticism, low risk. → Leans buy.

Decision: Buy. Score = 1 build, 6 buy. Buy a vendor. Spend the $300K you saved on marketing instead.

The alternative: The hybrid approach

Some companies split the difference: buy a platform and build custom agents on top.

For example: Buy Intercom Fin for standard support tickets (handle 70% of volume), but build a custom agent on Claude for complex escalations (handle 30% of volume, high-value tickets, or future product tie-ins).

This hybrid approach gives you:

  • Time to market (the bought solution is live in 6 weeks)
  • Custom differentiation (your built agent is proprietary and handles your 20% case)
  • Optionality (you can migrate all 100% to build, or all 100% to buy, later)

The hybrid approach is expensive in year 1 but gives you strategic flexibility.

When to revisit the build vs buy decision

Every 12 months, revisit this decision. Your answers might change:

  • You hire an ML team → building becomes viable
  • A vendor goes through a price increase → building becomes more cost-competitive
  • A vendor launches a new feature that handles your 20% case → buying becomes stronger
  • Your competitive advantage shifts to include AI → building becomes necessary

For deeper vendor evaluation, see "How to Buy AI: The Executive's Vendor Evaluation Guide." For cost modeling, see "AI Vendor Evaluation Framework: Cost, Control, and Outcomes."

Want to see this in your stack?

Book a 30-minute walkthrough with a Runrate founder.

Get a Demo

Was this article helpful?