the recommended way seems to be to build the core and buy the rest *FIXME: this is a stub at this point, elaborate more* ## generally, the recommended way seems to be to build the core and buy the rest > The best way to attack the essence of building software is not to build it at all. > — Frederick P. Brooks, The Mythical Man Month > When it comes to build versus buy, the frequently repeated but rarely followed wisdom is good advice: if you're a technology company, vendors usually generate significant value if they're outside your company's core competency; within your core competency, they generally slow you down > —Will Larson > If it’s a core business function — do it yourself, no matter what. > > Pick your core business competencies and goals, and do those in house. If you’re a software company, writing excellent code is how you’re going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you’re a web accounting service, write your own accounting package, but don’t try to create your own magazine ads. If you have customers, never outsource customer service. > > — Joel Spolsky, from [In Defense of Not-Invented-Here Syndrome](https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/) > Cores are the central competencies of the organization. These are things that customers are willing to pay for and what investors reward. Context is everything else. \[...\] As we fund core features and applications, we need to make sure that context doesn’t kill core. > > Of the applications and services that you manage, which of them are customers willing to pay you for? Which ones truly enhance competitive advantage? And which can you rely on vendors for? > > — Kim Gene, from [The Unicorn Project](https://www.goodreads.com/book/show/44333183-the-unicorn-project), chapter 17 ## some thoughts on the decision process - some buy vs. build decisions might be [[Cynefin framework|complex decisions]], thus experimentation might be a way forward - both options seem to have [[Map of risks|high risks that should be tackled up-front]] - so the goal of the experimentation might be to gather evidence for each type of risk - [[Strategy could be approached with Wardley Maps|Wardley Map]] might be helpful as well, to understand the context - where on the innovation curve is the product? and how does the product fit into the strategy of the business, as depicted by the [[Strategy could be approached with Wardley Maps|Wardley Map]]? ## some questions *The following has been gathered from Will Larson and Camille Fournier posts (see below for the links)* FIXME: clean this up, align with [[Map of risks|key risks]] - Value (is the product our core?) - Is the product enhancing the competitive advantage? - Are customers willing to pay for the product? - Do we need to adapt the product quickly, in terms of days or few weeks, to meet new business needs? - Can we build a small and very focused tool that wont need new features over time? - Why has nobody else built a solution for this? - What are we willing to build today? How will the quality and capabilities diverge over time? (Vendors have incentives to evolve, in-house tools less) - Is the product capable to support planned new business initiatives and partnerships (if any)? - Risk (FIXME: how could such risks be evaluated?): - How high is the risk the vendor go out of business? - How high is the risk of vendor increasing prices significantly? - Could the vendor suffer from a severe security breach? - Could the vendor cancel the business line? - Could we manage the vendor, that is could we issue report cards? - Cost: - How high are the integration costs (upfront cost so before the vendor starts generating value), such as building the integration, building auxiliary integrations (e.g. BI/DWH) - How high are the financial costs (contract costs, licenses costs, etc) - How high are operating cost (cost of outages; mandatory integration updates) - How high are evolution costs (the cost of moving partly out of the vendor system): is the vendor flexible to move a subset of work to a different vendor? - Team - Are team members willing to work on the integration? - Is the integration work aligned with what the team members seek, career-wise? - Is there domain knowledge to build the solution in-house? - Org biases - Are we aware of complexity of providing the main features next to the edge-cases? - Can we estimate the total cost of ownership if we built in house? - Do we tend to promote engineers who solve by building over engineers who solve by integration? ## Further reading: - [Build vs Buy by Will Larson](https://lethain.com/build-vs-buy/) - [Why is it so hard to decide to buy?](https://skamille.medium.com/why-is-it-so-hard-to-decide-to-buy-d86fee98e88e) by [[@Camille Fournier]] - [In defence of not invented here syndrom by Joel Spolsky](https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/). - https://jrott.com/posts/why-buy/