Product Decision Prompt: Build vs. Buy Framework
Your team needs to deliver a new system to support a product. You can either build it in-house or buy an off-the-shelf or SaaS solution.
Describe how you would decide whether to build or buy. Present a structured framework and explain how you would evaluate:
-
Cost and total cost of ownership.
-
Time to market.
-
Scalability and reliability.
-
Maintenance and operational burden.
-
Vendor lock-in and data portability.
-
Strategic differentiation: core versus commodity.
Also explain how you would gather data, compare options, de-risk the choice through pilots or proofs of concept, and make a recommendation.
Constraints & Assumptions
-
Treat build, buy, and hybrid as possible options.
-
Include product, engineering, security, legal, finance, procurement, and operations considerations.
-
Do not choose build or buy by default; tie the recommendation to strategic importance, constraints, and evidence.
-
Include exit strategy and vendor risk if buying.
Clarifying Questions to Ask
-
What system are we deciding on and what job must it perform?
-
Is this capability core to product differentiation or a commodity enabler?
-
What are the launch deadline, SLOs, security requirements, and budget constraints?
-
What integrations, data types, and compliance obligations are involved?
-
What internal team capacity and expertise do we have?
Part 1 - Define Requirements and Options
Explain how you clarify the problem, success outcomes, constraints, and possible options.
What This Part Should Cover
-
Jobs to be done, users, must-have capabilities, and non-goals.
-
Functional and non-functional requirements.
-
Build, buy, and hybrid options.
-
Success metrics and decision criteria.
Part 2 - Evaluate Criteria
Compare options across cost, time to market, scalability, reliability, maintenance, lock-in, data portability, and strategic differentiation.
What This Part Should Cover
-
Three- to five-year total cost of ownership.
-
Opportunity cost of engineering time.
-
Procurement, integration, migration, training, support, and exit costs.
-
Vendor SLA, security, compliance, roadmap dependency, and pricing risk.
-
Internal operational burden and long-term product control.
Part 3 - De-risk and Recommend
Describe how you gather data, run POCs or pilots, and make the final recommendation.
What This Part Should Cover
-
Vendor demos, reference checks, security review, architecture review, and integration spike.
-
Prototype or POC with real workflows and performance tests.
-
Weighted scorecard plus narrative recommendation.
-
Risk mitigation, contract terms, data portability, and exit strategy.
-
Decision review with stakeholders.
What a Strong Answer Covers
A strong answer separates commodity from strategic capabilities, quantifies total cost and opportunity cost, validates vendor and internal feasibility, and makes a recommendation with explicit trade-offs and risk mitigations.
Follow-up Questions
-
When would you buy now and build later?
-
How would you avoid vendor lock-in?
-
What if the vendor is faster but fails a security requirement?
-
What internal cost do teams usually underestimate?
-
How would your recommendation change if this capability became strategically differentiating?