Objective: Master the build/buy/bake decision framework for AI products, understanding when to develop custom solutions versus using existing AI services.
"The decision between building, buying, or baking AI is one of the most consequential in AI product development. Make it wrong and you waste years or miss your window."
Strategic AI Product Management
6.2 Build vs. Buy vs. Bake Decisions
The build/buy/bake framework helps product teams make strategic decisions about AI development. Building involves developing custom AI solutions from scratch when proprietary capability is essential. Buying means acquiring AI capabilities through acquisition or licensing when speed or unique advantages are paramount. Baking involves using existing AI APIs and services, often called building on top of existing platforms, which offers the fastest path to capability.
The Build Decision
Building custom AI makes sense when you need proprietary advantage that cannot be achieved any other way.
Building custom AI makes sense under specific conditions. You should build when you have unique data advantages, meaning proprietary data that creates model quality advantages your competitors cannot replicate. You should build when AI capability is a core differentiator central to your competitive position. You should build when you need complete control over model behavior and data, such as when downstream applications depend on predictable AI behavior. You should build when regulatory requirements mandate specific AI implementations that external providers cannot satisfy. You should build when you can achieve better economics than buying at scale, making the investment economically rational.
Build Considerations
Investment required: Building foundation models or significant model capabilities requires massive investment (millions to hundreds of millions of dollars). Even building specialized models requires substantial resources.
Time to value: Custom AI development takes time. You will not see results for months or years.
Talent requirements: You need ML engineers, researchers, and infrastructure expertise.
Stripe built custom models for code search and API recommendations because they had proprietary code and API data that gave them unique training advantages. Code understanding was core to their developer experience, making it a genuine competitive differentiator rather than a nice-to-have feature. General-purpose models did not understand Stripe-specific patterns, requiring customization to achieve acceptable quality. Their scale justified the investment, making the economics of custom development favorable compared to using commodity solutions.
Building requires significant commitment but creates proprietary advantage when done for the right reasons.
The Buy Decision
Buying AI capability through acquisition or licensing makes sense when speed is critical or when the target company has unique advantages.
Buying AI capability through acquisition or licensing makes sense under specific circumstances. Speed to market is a primary driver when building would take too long and competitive pressure demands faster action. Acqui-hire situations occur when you need the team more than the technology, valuing the human expertise over existing capabilities. Unique technology arguments apply when the target has capabilities unavailable elsewhere that would take too long to develop internally. Market position considerations matter when acquiring a competitor eliminates a threat and strengthens your competitive standing. Existing investment in the target company may have already solved problems you face, making acquisition more efficient than building from scratch.
Buying can accelerate your path to capability but carries its own integration risks and costs.
Buy Considerations
Integration challenges: Merging teams, technologies, and cultures is difficult.
Overpayment risk: AI valuations can be inflated.
Due diligence complexity: Assessing AI quality before acquisition is hard.
The Bake Decision
Baking (using existing AI APIs) is the most common approach for most AI features. It offers the fastest path to AI capability.
Baking, or using existing AI APIs, is appropriate under several conditions. Commodity capability is a primary reason when AI is not your core differentiator and generic functionality suffices. Speed priority drives the decision when you need to ship AI features quickly and cannot afford development time. Limited resources matter when you lack ML engineering capacity and cannot build custom solutions internally. Evolving technology considerations apply when you want flexibility to switch models as the AI landscape evolves. Table stakes features make baking the right choice when basic AI is expected but not differentiating, such as spam filtering or search relevance.
Bake Considerations
Commoditization risk: Everyone can access the same AI APIs, so you cannot differentiate on the base capability.
Dependency: You are at the mercy of API reliability and pricing changes.
Limited control: You cannot customize model behavior as deeply.
A mid-size SaaS company added AI-generated support ticket summaries using the OpenAI API with the following characteristics: total development time was just two weeks, ongoing cost was approximately one cent per ticket, integration complexity was low, and competitive differentiation was also low since anyone can access the same API and implement similar functionality. This was the right decision because AI-generated summaries were a nice-to-have rather than a core differentiator, making the speed and simplicity of baking more valuable than the potential advantage of custom development.
Baking works well when speed matters more than differentiation.
The Strategic Matrix
Companies that build their own AI often spend 2 years and $50M. Companies that bake APIs ship in 2 weeks and wonder why they have no moat. The answer: Build when you need control, not when you're impatient.
The strategic matrix reveals how each approach compares across key factors. Investment required varies dramatically, with building requiring very high investment, buying requiring high investment, and baking requiring low investment. Time to market follows an inverse pattern, with building taking long, buying taking medium, and baking delivering fast results. Differentiation potential is high for both build and buy approaches but low for baking, since everyone can access the same APIs. Control over AI behavior is full with building, variable with buying depending on deal terms, and limited with baking. Risk is high with building due to execution uncertainty, medium with buying due to integration challenges, and low with baking due to proven technology.
Making the Decision
Work through this framework systematically to make the right strategic choice. First, categorize by taxonomy, determining whether the AI capability is table stakes, a differentiator, or core to your product strategy. Second, assess data advantage, asking whether you have unique data that would improve the model and create proprietary benefit. Third, evaluate time constraints, determining how urgently you need this capability given competitive pressure. Fourth, consider resource availability, assessing whether you have the ML talent and infrastructure to build or whether you need to rely on external solutions. Fifth, calculate unit economics, determining the true cost of each approach including development, operational, and opportunity costs.
Before making any build/buy/bake decision, define how you will measure whether the choice was correct. A micro-eval for build/buy/bake compares: total cost of ownership across approaches, time-to-market impact, and strategic flexibility after each choice. A mid-size SaaS company's eval-first insight: they chose to "bake" AI summary features but measured API costs scaling 10x at 100K users. They pivoted to a hybrid approach with caching and saw 70% cost reduction while maintaining quality.
What's Next?
Next, we explore Value Proposition Design, understanding how to articulate and design value propositions for AI products.