Build-or-buy decision framework for a product capability: cost, speed, risk, control

How do you choose between developing a capability in-house and purchasing one that already exists? Walk through how you would make the call, and illustrate it with an example of your choice. ```hint Ask why customers choose you Before comparing costs, ask what role the capability plays in why customers pick your product, and whether that role is likely to grow or shrink over the next few years. ``` ### Clarifying Questions - Is the capability something customers see and choose us for, such as search ranking in a marketplace, or back-office plumbing, such as payroll or email delivery? - Does buying mean only licensing a vendor's product, or also adopting open-source software, partnering, or acquiring a company? - Is there a deadline, such as a launch date or a competitor's move, or is this a long-term platform choice? - How much engineering capacity and in-house expertise do we have in this area? ### What a Strong Answer Covers - Whether the capability differentiates the product or is a commodity, and how that could change - Multi-year total cost of ownership for both paths, including integration, maintenance and switching costs - Time to market, the team's ability to deliver, and the opportunity cost of engineering time - Risks on each side: vendor lock-in, data ownership, security and compliance, roadmap control, and in-house delivery risk - Hybrid options and a way to keep the decision reversible ### Follow-up Questions - A year after you buy, the vendor raises prices sharply and its roadmap drifts away from your needs. What do you do? - Engineering wants to build because the problem is interesting; leadership wants to buy for speed. How do you settle it? - How does the framework change for an AI capability, where the options are a hosted model, an open model you run yourself, or training your own?