How do you decide between building versus buying a technology solution?

Execution 1. Define core vs. context: Identify if the capability is a strategic differentiator (core) or a commodity (context). 2. Evaluate build costs: engineering time, maintenance, opportunity cost. 3. Evaluate buy costs: licensing, integration, vendor lock-in. 4. Assess time-to-market: build typically takes longer; buy offers speed. 5. Analyze scalability and control: build gives full control; buy may limit customization. 6. Perform a TCO analysis over 3-5 years. 7. Make a recommendation with clear rationale.

What They’re Really Asking

Do you have a structured, strategic approach to make cost-effective, time-sensitive decisions that align with the company’s core competencies and competitive advantage?

Framework: Use the 1. Define core vs. context: Identify if the capability is a strategic differentiator (core) or a commodity (context). 2. Evaluate build costs: engineering time, maintenance, opportunity cost. 3. Evaluate buy costs: licensing, integration, vendor lock-in. 4. Assess time-to-market: build typically takes longer; buy offers speed. 5. Analyze scalability and control: build gives full control; buy may limit customization. 6. Perform a TCO analysis over 3-5 years. 7. Make a recommendation with clear rationale. framework to structure your answer.

Strong Sample Answer

When deciding build vs. buy, I start by distinguishing core vs. context: if the technology directly supports our unique value proposition, we build; otherwise we buy. At my previous company, we needed a recommendation engine. After a build-vs-buy analysis, we found building from scratch would take 9 months and tie up 5 engineers—delaying other high-impact features. We bought a proven solution for $50k/year, integrated it in 3 weeks, and saw 18% lift in engagement within first quarter. That saved us ~$600k in engineering costs and let us focus on core product differentiators. I also negotiate strong SLAs and exit clauses to mitigate vendor risk, and set up a quarterly review to reassess if buying is still the best approach as our needs evolve. This structured process balances speed, cost, and long-term strategic alignment.

Common Mistake to Avoid

Don’t do this: Rushing to build because of NIH syndrome (not invented here) without fully accounting for hidden costs like ongoing maintenance, bug fixes, and opportunity cost of delayed features.

Company-Specific Variants

Amazon Variant

At Amazon, we apply the 'undifferentiated heavy lifting' principle: if the solution is not a competitive differentiator, we buy or use AWS services to reduce operational burden and focus on customer-obsessed innovation.

Google Variant

At Google, if the technology is a strategic lever for our core mission (e.g., organizing the world‘s information), we build—often open-sourcing it—but if it’s a commodity, we buy or use existing infrastructure to maximize speed.

Meta Variant

At Meta, we prioritize speed and iteration: we buy a quick solution to test a hypothesis, then gradually build a custom version if it scales and becomes a competitive advantage.

📚 Recommended Resource

The 0-1 PM Interview Playbook (2026 Edition)

Master every round of the PM interview with frameworks, sample answers, and company-specific strategies used by candidates who landed offers at FAANG+.

Get it on Amazon →

Related Execution Questions

How would you build a fraud detection system for an e-commerce platform?Walk me through how you would launch a product in a new international market