The build vs buy question comes up in almost every AI product planning conversation I've been part of. It's one of the decisions that most dramatically shapes what you ship, when you ship it, and whether it actually differentiates your product.
In traditional software, build vs buy is primarily a cost and speed question: can you buy this capability cheaply enough and fast enough that building it yourself isn't worth the effort? In AI, the decision is significantly more complex - the right answer varies by industry, by where your differentiation lives, by your data assets, and by the regulatory environment you operate in.
I've worked through this decision at Mamaearth (CPG / D2C), Edxcare (EdTech), and HCLTech (Healthcare / Enterprise). Each context produced different answers, and understanding why is more useful than the answers themselves.
The Four Options (It's Not Binary)
The first mental model correction: build vs buy is not a binary choice. There are at least four options:
- Build from scratch: Train your own models on your own data. Maximum differentiation potential, maximum investment, maximum time to market.
- Build on open-source foundations: Use open-source models (Llama, Mistral, Falcon) as your base, customize on your infrastructure. Good middle-ground on cost and control.
- Buy and customize: Use a commercial AI platform (Azure AI, AWS Bedrock, Google Vertex) and fine-tune or RAG-augment with your proprietary data. Vendor handles the model; you handle the differentiation layer.
- Buy and configure: Use a commercial AI product (Salesforce Einstein, Microsoft Copilot, OpenAI APIs) with minimal customization. Fastest to market, least differentiation.
Most AI product decisions are really about choosing among options 2, 3, and 4. Option 1 (full build) is the right answer for very few companies - primarily those building AI as their core product, with the data and talent to justify it.
The Decision Framework
Dimension 1: Where Does Your Differentiation Live?
This is the most important question. Start here before anything else.
- If differentiation lives in the model itself (your approach to the AI problem is the product): Build. Examples: Waymo's self-driving system, Deepmind's AlphaFold, Isomorphic Labs' drug discovery engine.
- If differentiation lives in your data: Buy the model, build the data pipeline and fine-tuning layer. Your proprietary data is the moat; the model is infrastructure. Examples: Spotify's recommendation engine (their data is the moat, not their model), most healthcare AI systems.
- If differentiation lives in your workflow integration: Buy and configure. The AI is a capability enhancement to a differentiated workflow, not the source of differentiation itself. Examples: most enterprise B2B SaaS adding AI features to existing workflows.
- If you're experimenting and don't know yet: Buy and configure. Prove the concept before committing to a build investment.
Dimension 2: Total Cost of Ownership
The TCO calculation for AI is different from traditional software because the costs are distributed across training, inference, and maintenance in ways that are easy to underestimate.
Build costs include:
- Data collection, cleaning, and labeling (often the largest cost and most underestimated)
- Model training compute (GPUs, cloud compute)
- ML engineering talent (significantly more expensive than software engineering)
- Inference infrastructure (serving models at production scale is not trivial)
- Ongoing retraining as data distributions shift
- Model monitoring, debugging, and maintenance
Buy costs include:
- Vendor licensing or API fees (often scales with usage in ways that are expensive at high volume)
- Integration engineering (connecting vendor APIs to your systems)
- Vendor dependency risk (pricing changes, API deprecation, company risk)
- Data egress and processing costs for sending data to vendor
The crossover point where build becomes cheaper than buy depends heavily on your usage volume and the complexity of your AI use case. For most enterprise AI applications, buy is cheaper at low-to-medium volume; build becomes competitive at very high volume or when vendor pricing has increased significantly.
My rule of thumb: If you're making fewer than 1 million AI API calls per month, buy almost certainly has lower TCO than build when you include full engineering costs. If you're above 10 million calls per month, run a rigorous TCO analysis - the build case may start to close.
Dimension 3: Vendor Lock-In Risk
Vendor lock-in in AI has dimensions that don't exist in traditional software:
- Model lock-in: Your prompt engineering, fine-tuning, and evaluation are optimized for a specific model. Switching models requires significant re-work.
- Data lock-in: If your training data or fine-tuning datasets live in a vendor's platform, extraction may be difficult.
- API dependency: If a vendor deprecates or significantly prices an API you depend on, your product breaks or your economics collapse.
- Capability ceiling: If your vendor's model capabilities plateau and your product requires more advanced AI, you may be stuck.
Mitigation strategies:
- Abstract your AI calls behind an internal interface so you can swap models without rewriting application code
- Maintain model-agnostic evaluation datasets so you can quickly assess alternative models
- Monitor vendor pricing quarterly and build a switching cost estimate into your strategic plans
- For critical AI capabilities, evaluate at least two alternatives annually to maintain optionality
Dimension 4: Regulatory Constraints
This dimension is industry-specific and often decisive.
Healthcare: HIPAA prohibits sending PHI to third-party AI systems without a Business Associate Agreement (BAA). Many consumer AI APIs don't offer BAAs, which means healthcare organizations must either use providers that offer BAAs, deploy models in their own infrastructure, or build themselves. This often pushes the decision toward open-source models deployed on-premise or in VPC environments, even when TCO would otherwise favor commercial APIs.
Financial Services: Model explainability requirements under ECOA and FCRA mean that buying black-box models for credit decisioning requires the vendor to provide explainability guarantees that many won't offer. This pushes some fintech use cases toward build-or-open-source, especially in underwriting and fraud decisions.
EdTech: FERPA and COPPA constraints on student data limit what can be sent to commercial AI APIs without specific consent mechanisms. Platforms serving K-12 often build or self-host to avoid data governance complications.
CPG/Retail: Relatively low regulatory constraints on AI use compared to the above industries. Buy almost always wins on TCO and speed, with the primary constraint being competitive sensitivity of proprietary consumer behavior data.
Dimension 5: Team Capability
Honest assessment: does your team have the capability to execute a build successfully? This means:
- ML engineers who can manage training infrastructure, model evaluation, and production deployment
- Data engineers who can build and maintain training data pipelines
- PMs who understand enough about AI to write meaningful specs and evaluate model quality
- Leadership willing to absorb the longer timeline and higher risk of a build approach
Most teams overestimate their capability for AI builds. The gap between "we have some ML engineers" and "we can build and operate production AI" is enormous. Underestimating this gap is one of the leading causes of failed AI initiatives.
Industry-Specific Calculus
Healthcare: Regulatory-First Thinking
In healthcare, the regulatory constraint often determines the answer before the economic analysis. If you're handling PHI, your options are vendors with BAAs (Azure, AWS, Google Cloud, Databricks - major platforms have them), self-hosted open-source, or build. The economic build vs buy analysis then happens within this constrained set.
My typical recommendation for healthcare organizations: start with buy (commercial platform with BAA), build your differentiation layer (clinical AI models fine-tuned on your patient population data, workflow integrations with your EHR), and keep the underlying foundation model as bought infrastructure.
CPG/D2C: Speed Is the Moat
In consumer goods and D2C, speed to market is often more valuable than technical differentiation. The competitive advantage in CPG is brand, supply chain, and customer relationships - not AI model quality. At Mamaearth, the right answer for almost every AI use case was buy-and-configure. We used Segment for data, commercial recommendation APIs, and vendor-provided personalization tools. We won on speed and data volume, not model sophistication.
FinTech: Compliance Complexity Shapes the Stack
In fintech, the explainability requirements for certain use cases (lending, insurance) make some commercial AI models unsuitable without vendor commitments to explainability. For back-office automation (document processing, customer service, operational workflows), buy dominates. For credit and underwriting, many organizations are building or using specialized AI underwriting vendors (Zest AI, Upstart's API) rather than general-purpose LLMs.
EdTech: Personalization Requires Your Data
In edtech, the differentiating asset is your understanding of how your specific student population learns. The base model is commodity; the adaptation layer informed by your learning data is the moat. The architecture of choice is buy-and-customize - commercial foundation model plus fine-tuning and RAG augmented with your proprietary learning outcome data.
The Build vs Buy Scorecard
I use a simple scoring exercise when the decision is unclear. Score each option from 1-5 on these dimensions:
- Speed to first user value
- Total cost of ownership over 3 years
- Differentiation potential
- Regulatory compliance confidence
- Team capability match
- Vendor risk exposure
No option wins on all six. The exercise surfaces which dimensions matter most for your specific situation and forces explicit discussion of tradeoffs rather than implicit assumptions.
There is no universally correct answer to build vs buy for AI. The correct answer depends on where your differentiation lives, what your regulatory environment requires, what your team can execute, and what your competitive timeline demands. The teams that make this decision well aren't the ones with the most sophisticated analysis - they're the ones who ask the right questions before committing to an architecture that will constrain their roadmap for years.
