Build vs BuyTo Build or to Buy: That is not the question A common question that comes up when providing software solutions is whether it’s better to buy a product or build your own, hence the expression, “Build vs Buy.” It’s seldom an accurate assessment of the situation for several reasons. First, buying usually means buying plus integrating and learning a new product. Second, you can seldom buy exactly what you would have built. Integration costs Whenever a product is purchased, it is highly unlikely that someone can simply click the Install button, and the product is immediately usable. More typically, the installation process alone is complex, and then to making it work for the specific needs of the organization can add a significant amount of development time, often requiring developers to learn the idiosyncrasies of that particular tool. Often, integration involves, creating a new database, at least partially populating the database; integrating security based on the needs of the organization, configuring various elements to make the system work. At the very least, the one should look at the entire process and compare them based on the end result. Consider the options in this scenario:
In this case, everything else being equal (we’ll get to that), it clearly makes sense to buy the product. If the product required 400 man/hours to integrate, then it might more sense to build it. As the integration effort increases, buying becomes less desirable. Licensing model Another consideration is the licensing model. Presumably, if you build it, you won’t pay new licenses per year, or per seat. If a product requires licenses to be paid per server, or per user, and/or the license needs to be renewed each year, the situation might favor building. Are you buying what you would have built? The answer to this is usually No. Suppose you need an application for all the people in your company to be able to type and print letters for correspondence. You might buy a product like Microsoft Word which has far more features than most user will ever realize. The product, you would have built would likely not have all those features (for better or worse), so the appropriate comparison, is to look at what you would have built, not the cost of having a team program something that replicates all the functionality of Word. In a scenario with a very common use case that is very much the same for any organization, it’s usually more practical to buy a product, rather than reinvent the wheel. A product like Word represent many thousands of hours of development time; it is as cheap as it is only because that cost can be spread across a billion users (according to Microsoft).
|