AI Build vs Buy: A CTO's Decision Framework

The build-versus-buy decision has always been central to the CTO role. But with AI, the stakes are higher, the options are more complex, and the consequences of getting it wrong are more expensive than most leaders expect.

Two failure modes recur: building an AI capability that a vendor could have provided in weeks for far less, and locking into a vendor dependency that becomes an existential risk when the vendor changes pricing, pivots or shuts down. Both are avoidable with a better decision framework.

Should a startup build or buy AI?

A startup should buy AI for commodity capabilities (transcription, summarisation, support automation) and build only where AI is the core differentiator and the company has unique data and the team to maintain it. Partnering fits specialised, regulated domains. Decide per capability, document the reasoning and set triggers to revisit.

This article lays out a practical framework for AI build-versus-buy decisions — including the third option that too many CTOs overlook: partnering.

Why AI Build vs Buy Is Different

Traditional build-versus-buy decisions involve relatively stable technology. If you build a payment system or buy Stripe, the capabilities of both options are well-understood and change incrementally. You can make a five-year decision with reasonable confidence.

AI is different in several important ways:

The technology is moving faster than your roadmap. A model you spend six months building may be outperformed by a general-purpose API release next quarter. The vendor you evaluated last month may have released a new tier or feature that changes the equation entirely.

The costs are harder to predict. Building an AI capability involves not just development cost but ongoing costs for training data, compute, model monitoring, and retraining. Plan for cost overruns and treat early estimates as ranges.

The talent is scarce and expensive. ML engineers who can take a model from research to production are among the most expensive and hardest-to-retain engineers in the market. Your build decision is also a hiring and retention decision. For practical guidance on building and structuring AI teams, see our guide on managing AI teams.

Data is the real moat, not the model. In most AI applications, the model architecture matters less than the data it is trained on. This means your build-versus-buy analysis should focus as much on data as on engineering.

What does the evidence say about AI productivity?

The evidence on AI and developer productivity is mixed, which matters for build-versus-buy because many cases rest on promised speed-ups. DORA's 2024 report associated higher AI adoption with an estimated 1.5% decrease in delivery throughput and 7.2% decrease in delivery stability, while its 2025 report found adoption at 90% and a positive link to throughput. Treat vendor claims as hypotheses and measure.

These are surveys of association, not controlled experiments. Measure delivery before and after any AI rollout using DORA's metrics, and see our evidence review of AI coding tools for the controlled studies and their designs.

When to Build

Building your own AI capability makes sense when several conditions align. If most of these are true, building is likely the right call.

Core Differentiator

If the AI capability is central to what makes your product unique — the thing that customers choose you for over competitors — you should probably build it. Outsourcing your core differentiator to a vendor means your competitive advantage is available to anyone who signs the same contract.

Illustrative example: A legal tech company whose product is AI-powered contract analysis built their own NLP models trained on millions of legal documents. The models are their product. Buying off-the-shelf NLP would have given them the same capability as every competitor.

Unique Data Advantage

If you have proprietary data that creates a meaningful advantage — data your competitors do not have and cannot easily acquire — building lets you leverage that advantage. A vendor's general-purpose model trained on public data cannot match a custom model trained on your unique dataset.

Illustrative example: A logistics company with fifteen years of delivery data built their own route optimisation model. No vendor had access to their historical delivery patterns, driver behaviour data, and customer preference signals. In this hypothetical, the custom model outperformed commercial alternatives.

Compounding Returns

If the AI capability gets better over time as you accumulate more data and user feedback — a data flywheel — building creates compounding advantage. Every customer interaction makes your model better, which makes your product better, which attracts more customers. This virtuous cycle is one of the strongest competitive moats in technology.

Illustrative example: A content platform built their own recommendation engine. Every user interaction generated training signal that improved recommendations, which increased engagement, which generated more training signal. In this hypothetical, the accumulated behavioural data made their recommendations better than off-the-shelf options.

Deep Customisation Required

If your use case has requirements that off-the-shelf solutions cannot meet — specific latency requirements, domain-specific accuracy needs, unusual data formats, or strict privacy constraints — building may be your only option.

Illustrative example: A healthcare company needed AI analysis of medical images with regulatory-grade accuracy, specific explainability requirements, and data that could never leave their infrastructure. No vendor met all three requirements simultaneously.

When to Buy

Buying — using a vendor's AI service via API or integrated product — makes sense in a different set of circumstances.

Commodity Capability

If the AI capability you need is generic — transcription, translation, text summarisation, basic image recognition, sentiment analysis — buying is almost always the right choice. These are problems where specialised vendors and open models are mature. Unless transcription is your product, you are unlikely to out-build them.

Speed to Market

If time matters more than customisation, buying gets you to market in weeks instead of months. For early-stage companies validating product-market fit, the speed advantage of buying is often worth the trade-offs in customisation and control.

Illustrative example: A startup building an AI writing assistant uses a vendor API to ship its MVP quickly. They could refine and potentially build their own models later if the product found traction. The alternative — spending six months building models before testing the product hypothesis — would have been a misallocation of limited resources.

Insufficient Team

If you do not have ML engineers and cannot hire them quickly, buying is the pragmatic choice. Building AI capabilities without ML expertise produces bad results slowly — the worst of both worlds.

This is not a permanent constraint. You can start with a vendor and build internal capability over time. But do not underestimate what "building internal capability" requires: not just hiring ML engineers, but building the infrastructure, processes, and organisational knowledge to develop and maintain AI systems.

Rapid Improvement Trajectory

If the vendor's capability is improving faster than you could improve a custom solution — which is the case for most general-purpose AI capabilities right now — buying keeps you on the leading edge without the investment of staying there yourself.

When to Partner

Partnering — deeper integration with a specialised AI company that goes beyond a simple API call — is the option CTOs most often overlook.

Specialised Expertise

Some AI domains require expertise that would take years to build internally: medical AI with regulatory requirements, financial AI with compliance constraints, industrial AI with safety-critical considerations. A partner who has spent years building this expertise can deliver results you simply cannot replicate in a reasonable timeframe.

Shared Data Advantage

In some cases, a partner has complementary data that combined with yours creates value neither could achieve alone. This is particularly common in industry-specific AI where training data is scarce and expensive to acquire.

Validation Before Commitment

Partnering can be a way to validate an AI use case before committing to building it yourself. Work with a partner to prove the concept, understand the data requirements, and measure business impact. Then decide whether to bring the capability in-house or continue the partnership.

Risk Sharing

Partners share the risk of AI projects in a way that vendors do not. A vendor sells you an API and wishes you luck. A partner has skin in the game — their success depends on your success. This alignment of incentives can be valuable for high-stakes AI initiatives.

The Cost Comparison Framework

The single biggest mistake in AI build-versus-buy decisions is underestimating the true cost of building. Here is what a realistic cost comparison looks like.

True Cost of Building

Development cost (Year 1):

• ML engineers (typically a small team): salaries, benefits, equipment and overhead. Use your own fully loaded cost per person from HR and your recruiter; we do not quote a market figure because it varies widely by location and seniority.
• Infrastructure: compute for training and serving, data storage, experiment tracking tools. Get quotes for your expected volume.
• Data: acquisition, cleaning, labelling. Highly variable: close to zero if you have clean internal data, and significant if you need to acquire or label external data.

Ongoing cost (Year 2+):

• Team maintenance: the team does not go away after the initial build. Models need monitoring, retraining, and improvement. Plan for ongoing headcount; the team does not disappear after the first release.
• Compute: training new model versions, serving predictions, handling growth.
• Opportunity cost: what else could those engineers have built?

Hidden costs people forget:

• Recruitment time and cost for ML engineers
• Ramp-up time for new ML hires (allow a ramp-up period before full productivity)
• Management overhead (who manages the ML team?)
• On-call and incident response for ML systems
• Model drift and degradation requiring retraining
• Eventual infrastructure migration as you outgrow initial setup

True Cost of Buying

Vendor cost:

• API pricing or subscription fees. Get quotes for your actual volume, not the published pricing page.
• Integration development. Budget 2-4 weeks of engineering time for a typical API integration, more for complex workflows.
• Ongoing maintenance of the integration. APIs change, vendors release new versions, deprecation happens.

Risk cost:

• Vendor lock-in. How hard is it to switch if the vendor raises prices, degrades quality, or shuts down?
• Data exposure. What data are you sending to the vendor? What are the privacy and security implications?
• Dependency. If the vendor has an outage, does your product break?

The real comparison:

Software projects commonly overrun their first estimates, and AI builds add data and maintenance costs that early plans miss. Buying costs are more predictable, but risk costs are often underestimated.

A rough heuristic (our own rule of thumb, not a research finding): if the vendor's annual cost is less than the annual fully loaded cost of one ML engineer, buying is almost certainly better. If the vendor's annual cost exceeds the cost of your entire ML team, the math shifts toward building — but only if you have the team and infrastructure to execute.

Real Decision Scenarios

Scenario 1: Customer Support Automation

A B2B SaaS company wants to automate tier-one customer support inquiries.

Analysis: Customer support automation is increasingly commodity. The company's support data is valuable but not unique enough to justify a custom model. Speed to market matters because support costs are growing faster than revenue.

Decision: Buy. Use a vendor like Intercom's AI, Zendesk AI, or a custom GPT integration. Invest engineering time in the integration and the feedback loop that routes edge cases to human agents, not in building models.

Scenario 2: Product Recommendation Engine

An e-commerce company with ten million users wants to improve product recommendations.

Analysis: Recommendations are a core differentiator — the quality of recommendations directly affects conversion and revenue. The company has years of user behaviour data that no vendor has access to. Better recommendations create a flywheel: better recommendations lead to more engagement, which generates more data, which improves recommendations.

Decision: Build. Hire two to three ML engineers, start with a well-understood approach (collaborative filtering, then layer in deep learning), and invest in the data pipeline that feeds the model.

Scenario 3: Document Processing

A financial services company needs to extract structured data from thousands of documents per day (invoices, contracts, forms).

Analysis: Document processing is a well-solved problem with strong vendor solutions (AWS Textract, Google Document AI, dedicated vendors like Rossum). The company has no unique data advantage — their documents are standard financial instruments. Regulatory requirements mean data must stay in specific regions.

Decision: Buy, with a partner evaluation for regulatory compliance. Select a vendor that offers region-specific deployment. If no vendor meets compliance requirements, partner with a specialised document AI company that serves financial services.

Scenario 4: Fraud Detection

A payments company wants to improve fraud detection accuracy.

Analysis: Fraud detection is core to the business — poor fraud detection either loses money to fraud or blocks legitimate transactions. The company has proprietary transaction data with rich fraud labels. Fraud patterns are specific to their merchant mix and cannot be generalised.

Decision: Build, but start with a vendor as a baseline. Use a fraud detection vendor immediately to establish a performance benchmark, then build custom models that leverage proprietary data to outperform the vendor. Transition gradually, running vendor and custom models in parallel during the transition.

Making the Decision

Here is a decision process we recommend:

1. Classify the capability. Is it core to your differentiation or commodity? This single question answers most build-versus-buy decisions.

2. Assess your data advantage. Do you have unique data that would make a custom model significantly better than a generic one? If yes, that tilts toward build.

3. Evaluate the vendor landscape. What is available? How good is it? How is it priced? Do a genuine evaluation, not a cursory glance.

4. Calculate the true build cost. Use the framework above, add a contingency to your initial estimate, and stress-test it. If the number still looks reasonable, building is viable.

5. Consider the timeline. How urgently does the business need this capability? Building takes months. Buying takes weeks.

6. Plan for change. Whatever you decide today, the landscape will be different in eighteen months. Make reversible decisions where possible. Design integration layers that let you swap vendors or replace a vendor with a custom solution later.

7. Set review triggers. Define conditions that would cause you to revisit the decision: vendor price increases above a threshold, team reaching a size where building becomes viable, accuracy requirements exceeding vendor capabilities, or regulatory changes that affect vendor suitability. Review proactively rather than waiting for a crisis.

8. Document the decision and reasoning. Use an architecture decision record (title, context, decision, status, consequences, per Michael Nygard) or equivalent. When you revisit this decision in twelve months — and you will — having the original reasoning documented saves enormous time and prevents revisiting settled questions.

Decision checklist for AI build vs buy

Answer yes or no for each capability. Mostly yes in the first five rows points to build; mostly yes in the last five points to buy or partner. This is a prompt for discussion, not a scoring model.

For guidance on building these decisions into a comprehensive AI strategy, see the CTO AI strategy guide. And for a broader perspective on the skills needed to navigate these decisions effectively, the CTO skills framework covers the technical leadership and business acumen dimensions that underpin good build-versus-buy judgment.

Take the Next Step

Build-versus-buy decisions for AI capabilities are among the most consequential choices you will make as a CTO. Getting them right requires a blend of technical understanding, business acumen, and strategic thinking that defines the modern CTO role.

If you want to assess your readiness across these dimensions, take the CTO Readiness Assessment. It takes about ten minutes and gives you a clear view of your strengths and gaps across the key CTO competencies.

---

Frequently asked questions

Should a startup build or buy AI?

Buy for commodity capabilities such as transcription, summarisation and support automation, where vendors are mature and speed matters. Build only when AI is your core differentiator, you hold proprietary data and you can hire and keep ML engineers. Decide per capability, and design integrations so you can swap a vendor for a custom model later.

When does fine-tuning make sense?

Fine-tuning makes sense when a general model underperforms on your domain and you have enough high-quality proprietary data to improve it, plus the team to evaluate and maintain the result. Start with a vendor model as a baseline, measure the gap on your own tasks, and fine-tune only if the gap justifies the added cost and maintenance.

How do you evaluate AI vendors?

Get quotes for your real volume, test accuracy on your own data, and check data handling, privacy and region options. Ask what happens if prices change or the vendor shuts down, how hard switching would be, and what an outage does to your product. Review the decision on set triggers rather than waiting for a crisis.

What is an AI data moat?

An AI data moat is a competitive advantage from proprietary data that rivals cannot easily obtain, especially when usage improves the model and the improved product attracts more usage. In most applications the data matters more than the model architecture, so assess your data advantage before deciding to build.

Does AI actually make developers faster?

The evidence is mixed. DORA's 2024 report associated higher AI adoption with an estimated 1.5% decrease in throughput and 7.2% decrease in stability, while its 2025 report found 90% adoption and a positive link to throughput, with only 24% trusting AI a lot or a great deal. Measure delivery before and after rollout.

Sources

1. Announcing the 2024 DORA report Google Cloud, 2024
2. DORA report 2025: State of AI-assisted Software Development Google, 2025
3. DORA metrics: the four keys (current five-metric model) DORA, 2026
4. Documenting Architecture Decisions Michael Nygard (Cognitect), 2011