Why this question dominates AI PM interviews
AI-forward companies ask build vs buy questions to test product judgment. The interviewer wants to see how you weigh speed, cost, control, and moat. A senior PM at OpenAI, Anthropic, or a Series B startup faces this choice each week. Should the team fine-tune a model or call GPT-5? Is Pinecone good enough, or do you need a custom RAG pipeline? Where does retrieval logic belong, in-house or with a vendor?
The phrase "it depends" is the wrong answer. A strong response applies a framework to specifics and names the tradeoffs.
A simple framework for the decision
Andrew Chen writes that the best PMs reason about defensibility before they reason about features (Chen, The Cold Start Problem). Apply that lens to AI components. Buy commodity capabilities. Build the parts that compound into a moat.
Three questions sort most decisions:
- Does this component touch our proprietary data in a way that creates a moat?
- Will vendor latency, cost, or reliability break our user experience?
- Can our team operate this safely at our current scale?
A yes on question one points toward build. A no on questions two or three points toward buy. Most real decisions blend both answers.
When to buy
Foundation models are the cleanest buy. Training a model from scratch costs tens of millions of dollars. Calling Claude or GPT-5 costs cents per query. Ethan Mollick notes that the gap between frontier labs and downstream builders keeps widening each year (Mollick, Co-Intelligence). A startup competing on model training loses the race. A startup competing on workflow, data, distribution, and brand can win the market.
Vector databases are usually a buy. Pinecone, Weaviate, pgvector, and Chroma all solve a well-defined problem. Your retrieval logic is the moat. The index is a commodity.
Embedding models are a buy at small scale. Open-source options run on commodity hardware. Hosted options cost less than the engineering time required for maintenance.
Observability tools like LangSmith and Helicone are a buy. Logging, eval, tracing, and replay for LLM apps is hard plumbing. In-house versions drain weeks from the roadmap.
When to build
Build when the component touches proprietary data outside vendor reach. A legal AI tool with ten thousand annotated case files holds training data outside the reach of any lab. Fine-tuning on that data creates a defensible product. Ben Horowitz argues that durable companies own a process more than a feature (Horowitz, The Hard Thing About Hard Things). Your training pipeline can be that process.
Tight control over user experience also pushes toward build. A real-time voice agent at sub-300ms latency cannot tolerate a network hop to a vendor. Hosting your own inference becomes the answer. A trading system with sub-50ms requirements needs custom infrastructure.
Compliance can force the decision. Healthcare and defense customers often refuse third-party data processors. SOC 2 and HIPAA constraints push toward self-hosted models. The cost of building is lower than the cost of losing the contract.
Scale eventually flips the unit economics. At one million queries per day, vendor API costs can exceed the fully loaded cost of a self-hosted model. Track your spend each month. Move in-house at the crossover point.
The hybrid path
Most senior PMs end up on a hybrid path. Buy the foundation model. Build the retrieval layer. Buy the vector store. Build the eval harness. Buy observability. Build the prompt orchestration logic.
Shreyas Doshi describes this as the high-leverage middle layer, where small product teams capture most of the value without owning the stack (Doshi, The PM Library). Your job is to find that middle layer inside your product.
A practical pattern follows this sequence. Start with vendor APIs in week one. Ship a working product in weeks four to six. Measure cost, latency, and quality. Replace components with custom builds only when data shows a clear win.
This sequencing protects against two failure modes. The first is over-building, where the team spends six months on infrastructure and never reaches users. The second is over-buying, where the team stacks vendors and ends up with no defensible product.
How to answer this in an interview
Senior PM interviews at AI companies often pose a scenario. The interviewer might say, "you join a Series A company building an AI sales assistant. Walk me through your build vs buy decisions for the first six months."
Strong answers move through four steps.
First, name the product goal in one sentence. Faster sales rep response times. Higher reply rates. Better lead scoring. Lower cost per qualified lead. Pick the goal.
Second, list the AI components the product needs. A language model, a retrieval system, an eval framework, an observability layer, a prompt manager, and a vector store.
Third, sort each component by the three questions in the framework. Walk through the logic step by step. Foundation model: buy, because no moat exists in pretraining. Retrieval over customer email history: build, because that data is the moat. Vector store: buy, because off-the-shelf options handle the workload. Eval harness: build, because quality bars vary by customer.
Fourth, name the risks. Vendor lock-in if a single provider has an outage. Cost overruns at scale. Hiring constraints for ML engineering talent. Quality regressions when vendors push silent model updates. The interviewer wants to see that you have thought past the happy path.
Aakash Gupta argues that AI PM interviews now test for systems thinking more than feature thinking (Gupta, The Product Compass). A build vs buy answer is your chance to show both skills.
Works cited
Chen, Andrew. The Cold Start Problem. Harper Business, 2021.
Doshi, Shreyas. The PM Library. Self-published, 2023.
Gupta, Aakash. The Product Compass. Substack, 2024.
Horowitz, Ben. The Hard Thing About Hard Things. Harper Business, 2014.
Mollick, Ethan. Co-Intelligence: Living and Working with AI. Portfolio, 2024.