Worked Example: Build vs. Buy AI Capability
Walk through a complete answer to 'Should we build or buy our AI capability?' covering cost analysis, competitive moats, and organizational readiness.
The Question
Here is the question: 'You are a VP of Product at a mid-size SaaS company (200 employees, $50M ARR). Your CEO wants to add AI-powered features to the product. Should you build your own AI capability in-house, buy/integrate third-party AI APIs, or acquire an AI startup? How would you decide?' This is the quintessential AI strategy question. It appears in some form in nearly every Director+ AI PM interview.
This question has no single right answer. The interviewer is evaluating your decision framework, not your conclusion. A well-reasoned 'buy' answer and a well-reasoned 'build' answer can both score a 5. A poorly reasoned answer of any kind scores a 2.
Worked Answer: Business Context and Ecosystem
"Let me start with the business context. At $50M ARR and 200 employees, this is a growth-stage SaaS company. The engineering team is probably 60-80 people. The AI/ML team is probably zero to three people. The company is likely optimizing for growth (acquiring customers, reducing churn) rather than cost efficiency. The CEO's interest in AI is likely driven by competitive pressure: customers are asking for AI features, or competitors are shipping them."
"For the ecosystem analysis, I need to consider what AI capabilities are available off the shelf. In 2025, the foundation model API landscape (OpenAI, Anthropic, Google) means that many AI features can be built using APIs without any ML infrastructure. Summarization, classification, extraction, and generation tasks that would have required a dedicated ML team 3 years ago can now be shipped by a product engineering team using API calls. This dramatically changes the build vs. buy calculus."
"The competitive landscape matters too. If AI features are becoming table stakes in our category (like AI-powered search in e-commerce, or AI writing assistance in document tools), speed to market is critical. If we are the first mover on AI in our category, we have more time to build a differentiated capability."
[Interviewer note: Good contextual framing. The candidate sized the engineering team realistically, identified the likely motivation for the AI push, and immediately recognized that the foundation model API ecosystem changes the traditional build vs. buy analysis. The competitive timing consideration is important.]
Worked Answer: AI Fit and Decision Framework
"Rather than giving a single recommendation, I want to propose a framework for deciding, because the right answer depends on three factors: the type of AI capability needed, the data advantage we have, and our timeline."
"For Type 1 AI features, which are general capabilities applied to our domain (summarization, search, classification, chatbots), I recommend buying. Specifically, integrating foundation model APIs. These tasks are well-served by off-the-shelf models with prompting and RAG (Retrieval-Augmented Generation). The build cost is low: a product engineer can integrate an API in 2-4 weeks. The competitive moat is not in the model; it is in the product experience around the model. A $50M ARR company should not hire ML engineers to build a summarization model."
"For Type 2 AI features, which are domain-specific capabilities that require our proprietary data (predicting customer churn, recommending actions based on usage patterns, anomaly detection on our specific data), the answer is more nuanced. If we have a strong data asset (years of customer usage data, unique labeled datasets), building gives us a competitive moat that buying cannot replicate. If our data asset is thin, buying a pre-built solution (not just APIs, but vertical AI SaaS tools) might be better until our data accumulates."
"For Type 3 AI features, which are core differentiating AI capabilities (AI is the product, not a feature), I would consider building or acquiring. If there is an AI startup that has the capability and the team, acquiring might be faster and better than building from scratch. But acquisition is expensive and risky for a $50M ARR company. I would only recommend acquisition if the AI capability is central to our 3-year product strategy."
[Interviewer note: The three-type framework is excellent. It avoids the trap of giving a single answer and instead provides a decision structure that accounts for different scenarios. The recommendation for each type is well-reasoned: buy for commodity AI, evaluate for domain-specific, consider acquisition only for core differentiators. This shows strong strategic thinking.]
Worked Answer: Metrics and Recommendation
"Here is how I would quantify the decision for each type. For Type 1 (buy via API): The cost is API usage (roughly $10K-50K/month at our scale) plus engineering time to integrate (2-4 weeks per feature). The ROI benchmark: the AI feature should generate at least 5x its cost in revenue impact or retention improvement within 6 months. If it does not, it is a nice-to-have, not a strategic investment."
"For Type 2 (build in-house): The cost is 2-3 ML engineers ($600K-900K annually) plus infrastructure ($100K-200K annually for compute and data tooling). The payback period needs to be under 18 months. The ROI benchmark: the proprietary model must outperform available third-party solutions by at least 15% on the key metric to justify the ongoing investment in maintaining our own ML stack."
"My overall recommendation for this company: Start with Type 1. Integrate foundation model APIs to ship 3-4 AI features in the next 6 months. This is fast, low-risk, and addresses the competitive pressure immediately. Simultaneously, invest in data infrastructure. Build a clean data pipeline, a feature store, and usage tracking that will enable Type 2 capabilities in 12-18 months. Hire 1 ML engineer now to own the data foundation, not to build models yet. Revisit the build vs. acquire decision for Type 2 and 3 capabilities in 12 months, when you have better data infrastructure and clearer signal on which AI capabilities are most valuable to your customers."
[Interviewer note: The quantified decision criteria for each type are specific and realistic. The overall recommendation is pragmatic and phased: start fast with APIs, build data infrastructure in parallel, and defer the bigger investment until you have more information. This is exactly the kind of strategic advice a board or CEO needs. Score: 4.5/5.]
Final Score and Debrief
Overall score: 4.5/5 (Strong Hire). This answer demonstrates exceptional strategic thinking. The three-type framework, quantified decision criteria, and phased recommendation are all marks of a senior PM who has thought deeply about AI strategy. The answer is also practical: it gives the CEO a clear action plan, not just an analysis.
To reach a 5/5: The candidate could have discussed vendor lock-in risk with foundation model APIs (what happens if OpenAI's pricing changes?), talent market considerations (hiring ML engineers in 2025 is competitive but more feasible than 2022), and the organizational change management required (the product team needs to learn how to ship AI features, which requires process changes beyond just technology choices).
Key Takeaways
- Build vs. buy is not a binary decision. Create a framework that maps different AI capability types to different strategies
- For commodity AI (summarization, search, chatbots), buy. The moat is in the product experience, not the model
- For domain-specific AI that depends on proprietary data, build if you have a strong data asset. Buy if your data is thin
- Quantify each option: cost, ROI benchmark, payback period. Strategy without numbers is just opinion
- The phased approach (API features now, data infrastructure in parallel, revisit build decisions later) is almost always the right starting strategy for mid-size companies