About
Media
Startups & Experiments
Writing
Topics
Resources
Contact
Posts
AI & TechnologyAugust 15, 2025 / 20 min

Build vs Buy AI: A 2026 Decision Framework for Founders

76% of enterprise AI use cases are now bought, not built. A founder's build vs buy AI framework: weighted scorecard, risk-adjusted TCO, use-case matrix.

VCVik ChadhaFounder • Operator • Investor
Build vs Buy AI: A 2026 Decision Framework for Founders
Part of the AI Adoption series
Explore topic
Expert Knowledge
25+ years building and investing in technology companies(A founder's framework from operating and investing across the 12+ companies I've built and invested in through Scalable Ventures, checked against 2024-2026 research from Menlo Ventures, MIT, Gartner, S&P Global, McKinsey and others)
For founders, the build vs buy AI decision now has a default answer: buy. In 2025, 76% of enterprise AI use cases were purchased rather than built internally (Menlo Ventures, 2025), up from 53% a year earlier, and in MIT NANDA's 2025 study external partnerships reached deployment about twice as often as internal builds. My verdict: buy by default, boost what you buy with your own data, and build only where AI is the product and you hold data nobody else has. Partner when you need something custom but don't have the team to own it. The stakes run in both directions. Build when you should have bought, and you burn your scarcest engineering months on a capability a vendor already sells. Buy when you should have built, and you hand your most important differentiator to a vendor who also serves your competitors. Below is the decision framework I use as an operator and investor: the four real options, what the data says, a weighted scorecard, a risk-adjusted 3-year cost model and a matrix by use case. Key takeaways
  • Buying is now the norm. Enterprises went from building 47% of AI solutions in-house in 2024 (Menlo Ventures, 2024) to buying 76% of use cases in 2025.
  • Bought tools ship more often. External partnerships reached deployment about 67% of the time versus about 33% for internal builds (MIT NANDA, 2025). Those outcomes are self-reported and correlational.
  • Most AI efforts stall either way. 42% of companies abandoned most of their AI initiatives before production in 2025, up from 17% a year earlier (S&P Global Market Intelligence, 2025).
  • Model cost rarely decides it. The price of GPT-3.5-level performance fell more than 280-fold in about two years (Stanford HAI AI Index, 2025). In my worked example, API spend is about 2% of a build's 3-year cost. People are almost all the rest.
  • Build only what differentiates. Score the decision, model risk-adjusted cost, and keep an exit path for anything you buy.

What Does "Build vs Buy" Mean for AI in 2026?

Build vs buy, sometimes called make or buy, is the question of whether to develop a capability in-house or purchase it. With AI it has more than two answers, because almost nobody builds from scratch. Even "building" usually means building on someone else's foundation model.

Build, Buy, Boost, Partner: The Four Real Options

MIT Sloan's write-up of MIT CISR research frames generative AI choices as buy, boost, or build (MIT Sloan, 2025). I add a fourth, partner, because it behaves differently from the other three.
OptionWhat it meansWhat you ownTypical example
BuyUse a vendor's finished product, or the AI built into tools you already pay forConfiguration and your usage dataCoding assistant, meeting notes, help-desk AI
BoostBuy a model or platform, then improve it with your data through retrieval (RAG), fine-tuning, prompts and workflowYour data layer, prompts, evaluations, the glue codeSupport assistant grounded in your help center
PartnerCo-develop with a vendor or specialist firm that brings the team and toolingWhatever the contract saysDocument-extraction pipeline built with a specialist
BuildYour team designs, trains or orchestrates the models and owns the stack and roadmapEverything, including the maintenanceAI that is the reason customers buy your product
Most founders who say they're "building AI" are boosting. That's usually the right call, and it carries a fraction of the cost and risk of a true build.

Why AI Changes the Old Software Build vs Buy Math

With classic software, most of the build cost is up front, and shipped code mostly sits still. AI is different. A working demo on a frontier model API takes days, which makes building feel easy. Ownership costs more than it looks: evaluation sets, monitoring for drift and hallucinations, model upgrades and data pipelines that keep running. And new models arrive every few months. As a16z's 2025 survey of 100 enterprise CIOs put it, "changing models is now a task that can take a lot of engineering time." So "Can we build this?" is the wrong question, since the answer is nearly always yes. Ask whether you want to own it for three years, and what your team won't build while it does.

What Does the Data Say: Are Companies Building or Buying AI?

The pendulum has swung twice in three years. Menlo Ventures' 2024 survey of 600 US IT decision-makers found that 80% of enterprises relied on third-party generative AI software in 2023. Then building surged: in 2024, "47% of solutions are developed in-house, while 53% are sourced from vendors." A year later it swung back. Menlo's 2025 survey of 495 US enterprise AI decision-makers found 76% of use cases purchased, and gave a plain reason: "ready-made AI solutions are reaching production more quickly and demonstrating immediate value."
YearBuilt in-houseBought from vendorsSource
2023about 20% (implied)80%Menlo Ventures, 2024 report
202447%53%Menlo Ventures, 2024 report
2025about 24% (implied)76%Menlo Ventures, 2025 report
The 2023 and 2025 in-house shares are implied, not stated by Menlo. Menlo's 2025 report also found that 47% of AI deals go to production, compared with 25% for traditional SaaS, nearly twice the rate. Enterprises spent $37 billion on generative AI in 2025, against $11.5 billion in 2024, with $19 billion of it at the application layer, and startups earned nearly $2 in AI application revenue for every $1 earned by incumbents.

Bought vs Built: Which Succeeds More Often?

MIT NANDA's The GenAI Divide: State of AI in Business 2025 combined a review of 300+ public AI initiatives, 52 organization interviews and 153 senior-leader survey responses. Its headline comparison: "external partnerships with learning-capable, customized tools reached deployment ~67% of the time, compared to ~33% for internally built tools." Read the caveats before you quote that ratio. The authors say the figures "reflect self-reported outcomes," and that the gap "may reflect organizational capabilities rather than implementation approach alone." Companies that buy well may simply be better-run companies, and the hybrid path had "insufficient data to quantify." Treat 67% versus 33% as a strong signal, not a law. The same report found top-performing mid-market firms averaged 90 days from pilot to full implementation, while enterprises with more than $100 million in revenue took nine months or longer. Speed is a startup's structural advantage, and a year-long build gives it away. My view: a bought solution shipped this quarter usually beats a better custom one shipped next year.

Why AI Project Failure-Rate Numbers Disagree

Claims that 30% to 95% of AI projects fail aren't contradictory. They measure different things, at different stages, with different evidence.
SourceWhat it measuresNumberType of evidence
MIT NANDA, 2025Custom enterprise GenAI tools reaching production5%Interviews; "directionally accurate"
MIT NANDA, 2025Organizations getting zero return on GenAI95%Interviews; directional
MIT NANDA, 2025Deployment rate, external partnership vs internal build~67% vs ~33%Self-reported; correlational
S&P Global, 2025Companies abandoning most AI initiatives before production42% (up from 17%)Survey, n=1,006
S&P Global, 2025Projects scrapped between proof of concept and broad adoption46%Survey, n=1,006
Gartner, 2024GenAI projects abandoned after proof of concept by end of 2025At least 30%Prediction
Gartner, 2025Agentic AI projects canceled by end of 2027Over 40%Prediction
RAND, 2024AI projects that fail, vs non-AI IT projectsOver 80% (2x)Prior estimates RAND cites
IBM, 2025AI initiatives that delivered expected ROI25%CEO survey, n=2,000
Menlo Ventures, 2025Bought AI deals that reach production47% (vs 25% for SaaS)Survey, n=495
MIT's 95% refers to organizations getting "zero return" on "$30–40 billion in enterprise investment into GenAI," and its 5% applies to custom enterprise tools reaching production with measurable KPIs. Menlo's 47% counts purchased deals. Different populations, so both can be true. RAND's 2024 report is often quoted as saying 80% of AI projects fail, but RAND attributes that to prior estimates: "By some estimates, more than 80 percent of AI projects fail." Its own research, interviews with 65 experienced data scientists and engineers, found the first root cause is that stakeholders "misunderstand—or miscommunicate—what problem needs to be solved." The two Gartner figures are forecasts, and the 2024 one blames "poor data quality, inadequate risk controls, escalating costs or unclear business value." IBM's 2025 CEO study found just 16% of AI initiatives scaled enterprise-wide. Adoption isn't the problem: McKinsey's 2025 State of AI survey found 88% of organizations use AI regularly in at least one function, yet only about a third have begun to scale and just 39% report enterprise-level EBIT impact. Menlo's 2024 survey shows why pilots die: implementation costs (26% of failed pilots), data privacy (21%), disappointing ROI (18%) and technical issues including hallucinations (15%). My reading: most AI efforts never reach durable production. Bought or partnered solutions do measurably better, but the evidence is correlational, so build only where you have a specific reason to be the exception.

When Should You Buy AI?

Buy AI when one or more of these is true:
  1. The capability is a commodity. Writing help, meeting notes, transcription and generic chat are solved problems (here are the tools I actually use). A simple test: if a competitor added this exact capability tomorrow, would your customers switch? If not, it's a supporting function. Buy it.
  2. Speed matters more than control. If competitors are already shipping AI features, a quarter matters. Bought tools skip the infrastructure, evaluation and hiring work that consumes the first months of a build, which is Menlo's explanation for the swing to buying.
  3. You don't have an ML or LLMOps bench. The US median wage for computer and information research scientists was $140,300 in May 2025, and employment is projected to grow 22% from 2025 to 2035 (US Bureau of Labor Statistics). That excludes equity, benefits and hub-market premiums. If you have no technical leader who can evaluate models, a fractional CTO is a cheaper first step than a hire.
  4. A proven vendor has already seen your edge cases. A vendor serving thousands of customers has met failure modes you'd take years to encounter, and debugged them in production.
  5. The AI lives inside a system you already use. If your CRM or help desk ships the capability natively, the integration is done. a16z's 2026 CIO survey found 65% of large enterprises prefer incumbent solutions when available.
For a CFO, buying turns an uncertain build budget into a predictable subscription. Model per-seat or per-action pricing at two or three times today's usage before you sign.

When Should You Build Custom AI?

Build custom AI, usually on top of foundation models, when these conditions hold:
  1. You have a proprietary data advantage. Data that is unique, growing and cleared for use (transaction histories, workflow outcomes, domain labels) can make a model beat any generic tool. Count the data your product will generate: at 100 customers you may not have enough, at 10,000 you may have a moat.
  2. AI is your core differentiator. If customers choose you because of the AI, you need full control of its behavior, quality and roadmap. Otherwise your roadmap is hostage to a vendor's.
  3. Regulation or data residency requires control. Healthcare, financial services and defense buyers often require self-hosting, audit trails or explainability that a vendor can't provide.
  4. Your volume makes per-call fees dominate. This is the weakest reason for most startups, and it weakens every year. Stanford's AI Index 2025 found the cost of GPT-3.5-level performance "dropped from $20 per million tokens in November 2022 to just $0.07 per million tokens by October 2024" (the price of hitting a fixed benchmark score, not one model's price history). Epoch AI (2025) estimates prices for a given capability fall 9x to 900x per year depending on the task, though it cautions the fastest drops may not persist. Anthropic's price list shows its top tier going from $15 / $75 per million input / output tokens (Claude Opus 4 and 4.1) to $4 / $20 (Opus 5.5), with a 50% Batch API discount. Run the sensitivity in the TCO section before you rely on this reason.
My rule of thumb, and it is only a heuristic: build when at least two of these four are true and one of them is #1 or #2. Regulation or volume alone usually points to boosting or self-hosting a bought model, not building your own.

What About the Middle Path: Boost or Partner?

RAG vs Fine-Tuning: Which Should You Try First?

Boosting is where most founders should spend AI engineering time. Try these in order:
  1. Prompting and workflow design. Structured prompts and tool calls solve more than founders expect. Start here, and build an evaluation set: real examples with known good answers you re-run whenever something changes.
  2. Retrieval-augmented generation (RAG). Use RAG when the model needs your facts: help-center articles, contracts, tickets, product data. It keeps data in your systems, lets the model cite sources and updates when your documents do.
  3. Fine-tuning. Fine-tune when you need consistent behavior rather than knowledge: a fixed output format, a house tone, or a narrow task you want done faster or more cheaply on a smaller model. It needs good labeled examples and must be redone when you change base models.
In practice most production systems use both, and neither is "building a model." Both keep you on someone else's foundation model while your data does the differentiating.

Build, Buy, or Partner: When Does Partnering Make Sense?

Partner when you need something genuinely custom, don't have the team to own it, and can't wait to hire one. The specialist brings the stack; you bring the data and the problem. MIT's 67% figure describes exactly this ("external partnerships with learning-capable, customized tools"), and it found strategic-partnership pilots "2x as likely to reach full deployment." Before you sign, settle who owns the models, prompts and training data; whether the partner can reuse what they learn from your data; how the work is handed over; and who maintains it in year two.

How Do You Run a Build vs Buy Analysis for AI?

A build vs buy analysis is a structured comparison of the options on strategic fit, cost and risk over a fixed horizon. Here is the five-step process I use:
  1. Define the problem and the metric. Write one sentence on the business problem and the number that will tell you it's solved. RAND's top root cause of AI failure is misunderstanding the problem, so this step does the most work.
  2. Score the decision on the weighted scorecard. Rate the eight criteria in the scorecard, apply your stage's weights and read the result.
  3. Model a risk-adjusted 3-year total cost of ownership. Count people, usage and fees for every option, then divide by the probability each one actually reaches deployment.
  4. Choose the path and design your exit. Pick buy, boost, partner or build, then write down how you'd leave: data export, contract terms and the evaluation set you own.
  5. Set a review date. Revisit the decision every year or at each funding stage, because prices, vendors and your own data all change.

The 30-Second Version

For a quick first pass, this decision tree gets you to a sensible default:
Build vs Buy AI Decision Tree
Is AI a core differentiator for your product?
CORE
Do you have unique, proprietary data?
YES
BUILD on foundation models
NO
Can you wait 6+ months for value?
YES
BOOST or PARTNER, then reassess
NO
BUY + customize
SUPPORTING
Does a proven solution exist?
YES
BUY off-the-shelf
NO
PARTNER or build lightweight

The Weighted Build vs Buy AI Scorecard

Real decisions aren't binary, so I use a weighted scorecard. Score each criterion from 1 (strongly favors buying) to 5 (strongly favors building), multiply by your stage's weight and add the results.
CriterionWhat a "5" looks likeSeed weightSeries A weightSeries B+ weight
Strategic differentiationCustomers buy because of this AI25%25%25%
Proprietary data advantageUnique, growing, rights-cleared data20%20%20%
Time-to-value toleranceYou can wait 6+ months for results15%15%10%
In-house ML / LLMOps capacityA dedicated team with evaluation and monitoring15%10%10%
Volume and unit economicsUsage high enough that per-call fees dominate cost5%10%15%
Regulatory and data-residency controlYou must self-host or audit model behavior10%10%10%
Vendor-market maturity (inverse)No credible vendor exists5%5%5%
Lock-in risk if boughtA vendor would hold your core workflow hostage5%5%5%
Reading the score: below 2.6, buy. From 2.6 to 3.5, boost or partner (buy, then customize with your data). Above 3.5, build on foundation models. These weights and thresholds are my starting points, not research findings, so calibrate them. Weight shifts from team capacity to volume as you grow, because a Series B company can hire and is likelier to have usage that makes fees bite. On vendor maturity, be skeptical of vendor counts: Gartner estimates that "only about 130 of the thousands of agentic AI vendors are real." Score a market as immature if the credible options are thin. Two illustrative examples (hypothetical, not from my portfolio):
  • A seed-stage SaaS adding AI support-ticket triage. Differentiation 2, data 3, time tolerance 1, team capacity 1, volume 1, regulatory 2, vendor maturity 1, lock-in 2. Weighted with seed weights: 0.50 + 0.60 + 0.15 + 0.15 + 0.05 + 0.20 + 0.05 + 0.10 = 1.80. Buy.
  • A Series A company whose product is an AI risk-scoring engine trained on its own customer outcomes. Differentiation 5, data 4, time tolerance 3, team capacity 3, volume 3, regulatory 3, vendor maturity 4, lock-in 4. Weighted with Series A weights: 1.25 + 0.80 + 0.45 + 0.30 + 0.30 + 0.30 + 0.20 + 0.20 = 3.80. Build on foundation models.

What Does Building AI Really Cost? A 3-Year TCO Worked Example

"How much does it cost to build an AI?" has no single answer, but people always dominate. Here's a worked total cost of ownership example for the first scenario above: a supporting AI triage feature at a seed or Series A B2B SaaS company. Assumptions (mine, labeled as such): a 1.3x fully loaded cost multiplier on base salary; two engineers in year one and one in each of years two and three for the build (the later years cover evaluation, monitoring, model upgrades and fixes); a quarter of one engineer in year one to integrate the bought tool; 50 million input and 10 million output tokens a month; and a $2,000/month vendor fee, which is a placeholder for a real quote. Swap in your own salaries, team size, volumes and vendor quotes.
Line itemBuildBuyInput source
Engineer base salary$140,300$140,300BLS median, May 2025
Fully loaded cost per engineer-year (×1.3)$182,390$182,390Assumption
Engineering effort over 3 years4 engineer-years = $729,5600.25 engineer-years = $45,598Assumption
Model API usage ($400/month × 36)$14,400Included in feeAnthropic list price, Opus 5.5 ($4 / $20 per million tokens); volume is an assumption
Vendor subscription ($2,000/month × 36)n/a$72,000Placeholder
3-year nominal TCO$743,960$117,598Calculated
Probability of reaching deployment~33%~67%MIT NANDA, 2025 (correlational)
Risk-adjusted cost per successful deployment≈ $2.25M≈ $175,500TCO ÷ probability
The math: 50 million input tokens at $4 per million is $200, plus 10 million output tokens at $20 per million is $200, so $400 a month. Dividing each total by its deployment probability gives expected spend per success at those odds: $743,960 ÷ 0.33 ≈ $2.25 million, and $117,598 ÷ 0.67 ≈ $175,500. What the example shows:
  • Model cost is about 2% of the build's 3-year TCO. People, evaluations and maintenance are the rest. At startup volumes, "build to save on API fees" rarely survives a spreadsheet.
  • The nominal gap is about 6x. Risk-adjusted, it's about 13x. Most build vs buy analyses ignore the probability of failure, the biggest variable in the decision.
  • Volume changes the picture. At 100 times the usage (5 billion input and 1 billion output tokens a month), API spend at the same list price reaches $40,000 a month, or $1.44 million over three years, and becomes the largest line. Batch pricing halves that for work that isn't real-time, and a vendor priced per action would scale its fee too. That's when the volume case for building or self-hosting becomes real.
  • Treat MIT's ratios as a stress test, not a forecast. If you can't argue why you'd beat a 33% deployment rate, budget as if you won't.
For scale, Gartner put enterprise GenAI deployment approaches at "$5 million to $20 million." The qualitative comparison matters too:
Cost factorBuildBuy
Upfront costHigh: mostly engineering timeLow: setup and integration
Ongoing costEngineers for evaluation, monitoring and upgradesSubscription or usage fees that scale with use
Time to valueMonthsDays to weeks
Opportunity costHigh: your best engineers off the core productLow
Switching costLow: you own itModerate to high: data, workflows and contracts
CustomizationUnlimitedLimited to what the vendor exposes
Model riskYoursShared with the vendor

Build vs Buy by Use Case: A Decision Matrix

These defaults are my judgment as an operator, not statistics. Run the scorecard on anything close to your core product.
Use caseDefaultWhy
Coding assistantsBuyCommodity, improving monthly, and not what customers pay you for
Meeting notes, writing, internal productivityBuySolved problems with mature vendors
Customer-support chatbot or ticket triageBuy, then boost with RAG on your help centerVendors are mature. Your knowledge base is the differentiator
Sales and marketing content, AI SDR outreachBuySupporting function. Differentiation is your offer, not the tool
Voice agents for support or schedulingBuy, unless voice is your productHard to build well; vendors have the telephony and latency work done
Document extraction and back-office automationBoost or partnerYour documents and rules matter, but the base capability is sold widely
Agents inside systems of record (CRM, ITSM, ERP)Buy embeddedIntegration depth lives with the platform vendor
AI infrastructure: evaluation, observability, gatewaysBuyNot a differentiator at startup scale
Core product intelligence customers pay forBuild on foundation modelsDifferentiator plus proprietary data
Regulated decisioning in health or financeBuild or partner, self-hostedControl, auditability and data residency

Should You Build or Buy AI Agents?

Agents raise the stakes because they take actions. Gartner predicts that "over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls" (Gartner, 2025). It also predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. Adoption is early: McKinsey's 2025 survey found 23% of organizations scaling an agentic AI system, with 39% experimenting. My guidance for founders:
  • Buy agents embedded in your systems of record. The agent in your CRM or help desk already has the permissions, data and audit trail.
  • Build orchestration only for workflows that are core to your product. If the agent is the product, own the planning logic, tool permissions and evaluation, and buy the underlying models.
  • Diligence the vendor hard. Given Gartner's "agent washing" estimate, ask for production references, failure handling, cost per completed task and what happens when the agent is wrong. My AI due diligence framework for evaluating AI startups works just as well on vendors.

How Do You Avoid Vendor Lock-In When You Buy?

Lock-in is less about technology than habit. Menlo's 2025 mid-year LLM market update found "only 11% of teams report changing model providers in the past year," while "66% upgraded to newer models from their existing vendor, while 23% made no changes." Meanwhile a16z's 2026 survey found 81% of large enterprises use three or more model families, up from 68%, and its 2025 survey found 37% use five or more models. Teams want options, then rarely use them. Build the exit in from day one:
  • Data export. Confirm in writing that you can export your data, conversation logs and configurations in a usable format.
  • A model-agnostic layer. Route model calls through your own thin abstraction so a provider change is a configuration change, not a rewrite.
  • Training rights. Get a clear contract term on whether the vendor may train on your data, and what happens to it when you leave.
  • Your own evaluation set. Keep the test cases and scores in your systems. They let you compare a new vendor or model in days.
  • Pricing protection. Cap price increases at renewal, and understand how per-action pricing behaves at higher volume.

Buy Now, Build Later: Capture the Data While You Learn

Buying first is the cheapest way to learn what you'd build. A bought tool validates demand, shows which requirements matter and, if your contract lets you keep logs and outcomes, accumulates the data you'd need for evaluation or training later. But be honest about which way the traffic usually flows. a16z reports that "many enterprises expect to migrate from DIY LLM implementations to packaged applications over time." Plan to build later only if the review date in step 5 produces a reason to.

How Should Your Build vs Buy Strategy Change as You Scale?

Today's right answer may be wrong in 12 months. Your data, team and priorities change, and so do the scorecard weights:
  • Seed stage: buy almost everything. Your engineering team is tiny and should focus on the core product.
  • Series A: buy supporting AI and start building core AI if it's your differentiator. You now have more data and some engineering capacity.
  • Series B and beyond: build what's strategic, buy what's operational. Vendor dependency on core capabilities becomes a liability, and volume may justify owning more of the stack.
This is the same principle I learned scaling an outsourcing business: outsource context, never core. Revisit your decisions every year. What you bought at $1M ARR might need to be built at $10M ARR, and what you built early might be better bought once vendors catch up. A CFO should own the risk-adjusted TCO and the usage-based pricing sensitivity. A CTO should own the evaluation set, the model-agnostic layer and an honest estimate of the team's capacity. A chief data officer should own data rights: what's proprietary, what's cleared for training and what a vendor is allowed to keep. The CEO owns the differentiation call, because it's a strategy question. My AI strategy guide for CEOs covers how to set those priorities, and Leadership in the Age of AI covers the team side of the change.

Sources

Related Reading

Get Expert Guidance

If you're working through a build vs buy decision for AI:

Frequently asked questions

What is build vs buy in AI?

Build vs buy in AI is the decision whether to develop an AI capability in-house or purchase it from a vendor. In practice there are four options: buy a finished product, boost a bought model with your own data through retrieval (RAG) or fine-tuning, partner with a vendor or specialist to co-develop it, or build it yourself on top of foundation models. Most companies now default to buying: Menlo Ventures found 76% of enterprise AI use cases were purchased in 2025, against 47% built in-house in 2024.

Is it cheaper to build or buy AI, and how much does custom AI cost?

For most startups, buying is far cheaper because people, not model fees, dominate the cost of building. In my worked 3-year example for a supporting AI triage feature (with labeled assumptions: a 1.3x fully loaded multiplier on the $140,300 BLS median wage, four engineer-years, and a placeholder $2,000/month vendor fee), the build costs about $743,960 and the buy about $117,598. Adjusted for MIT NANDA's self-reported deployment rates of about 33% for internal builds and 67% for external partnerships, that is roughly $2.25M versus $175,500 per successful deployment. API usage was only about 2% of the build cost. Swap in your own numbers.

What is a build vs buy analysis, and how do you run one for AI?

A build vs buy analysis compares your options on strategic fit, cost and risk over a fixed horizon. For AI, run it in five steps: define the business problem and the metric that shows it's solved; score the decision on a weighted scorecard covering differentiation, proprietary data, time-to-value, team capacity, volume, regulation, vendor maturity and lock-in risk; model a risk-adjusted 3-year total cost of ownership; choose buy, boost, partner or build and design your exit; and set a date to revisit the decision.

Should startups build or buy AI?

Startups should buy by default, boost what they buy with their own data, and build only where AI is the product and they hold data nobody else has. At seed stage, buy almost everything; at Series A, start building core AI if it is your differentiator; at Series B and beyond, build what is strategic and buy what is operational. Speed is a startup's advantage: MIT NANDA found top-performing mid-market firms averaged 90 days from pilot to full implementation, while enterprises took nine months or longer.

Why do most AI projects fail, and does buying reduce the risk?

Failure figures vary because they measure different things. S&P Global found 42% of companies abandoned most of their AI initiatives before production in 2025, up from 17%; Gartner predicted at least 30% of GenAI projects would be abandoned after proof of concept by the end of 2025; and RAND cites estimates that more than 80% of AI projects fail. RAND's top root cause is misunderstanding what problem needs to be solved, and Menlo found implementation cost was the most common reason pilots failed. Buying appears to help: MIT NANDA found external partnerships reached deployment about 67% of the time versus about 33% for internal builds, though those outcomes are self-reported and correlational.

Should you build or buy AI agents?

Buy agents embedded in the systems of record you already use, such as your CRM or help desk, and build orchestration only for workflows that are core to your product. Diligence vendors carefully: Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 and estimates only about 130 of the thousands of agentic AI vendors are real. McKinsey's 2025 survey found 23% of organizations are scaling an agentic AI system, so adoption is still early.

When should you build, buy, or partner for AI?

Buy when the capability is a commodity, speed matters, you lack an ML team, or a proven vendor exists. Build on foundation models when AI is your core differentiator and you have a proprietary data advantage, or when regulation requires full control. Partner when you need something custom but don't have the team to own it and can't wait to hire one; settle ownership of models and data, reuse rights, handover and year-two maintenance in the contract.

Should I use RAG or fine-tuning before building a custom model?

Yes. Try prompting and workflow design first, with an evaluation set of real examples. Use retrieval-augmented generation (RAG) when the model needs your facts, such as help-center articles, contracts or product data, because it keeps data in your systems and updates when your documents do. Use fine-tuning when you need consistent behavior, such as a fixed format, tone or a narrow task on a smaller model. Most production systems use both, and neither requires building your own model.
Scalable Ventures logo
Flagship VentureFounder & CEO of Scalable Ventures — The AI-focused studio where I build, fund, and scale capital-efficient B2B SaaS.
Visit Scalable Ventures

Related Articles

Explore more insights on entrepreneurship, AI, and leadership:

Explore More

Dive deeper into related topics and resources:
On this page