Please don't call it Build versus Buy

Photo by Sam Guenther on Unsplash

In the United States we just finished income tax season. Like many people I do my own taxes with the assistance of one of the major tax software packages (the one I actually use is not important). I purchased the software at a local office super store. I installed the package off of the CD by clicking a couple of buttons on the wizard. I updated the software online several times (over the course of several weeks). I gathered all my data and answered all the questions. In the end I filed electronically and all was well. I spent a total of about 5 hours on my taxes and saved several hundred dollars over going to a tax professional.

Buying a single user software system (such as the tax software) is as close to a pure “buy” in the “buy versus build” decision as any of us will ever get when there is custom data involved in the application. But most companies will spend a lot of time and energy discussing / debating / arguing the question of should they buy or should they build without ever question the fact if they are actually buying a solution or not.

Buy then build is what we usually do

When we buy a package based solution of any complexity it does not usually come “out of the box” ready to use like the tax software that I used to do my income taxes. There is a lot of work that needs to be done to get the application running in your environment. I am speaking of activities beyond actually installing the application on the servers and desktops (which can be complicated in and of itself). Even in something as simple as a General Ledger application included in an accounting package there are literally dozens of decisions that need to be made before the system can be brought online and loaded with your data. And often times, loading of the data is the hardest part of all.

We (as an industry) tend to compare the cost of building a solution with the cost of purchasing a package based system. When we do the math, we usually include a very naive and extremely low estimate of the cost of getting the software up and running. We tend to underestimate all the configuration, test and integration cost (that usually involves some software development) to get the package integrated into our environment.

Configuration is building

If you have ever been through the due diligence process on a packaged based software evaluation, you will often hear from the vendor something to the effect of “that is a configuration item, not custom code”. The vendor is telling you that this is a parameterization option in the software. While you may not have to write code to get it to work, you do have to get the parameters correct and more importantly, you have to test the application with the specific parameters that you have configured and you have to do all that in the presence of your data. The configuration process is “building” software, even though it is not writing code. I have actually been involved in packaged based implementations where there have been literally dozens of people on the “configuration team”. They may not be developers, but these are still resources that you need to acquire (sometimes scarce resources that can cost you more than developers).

Yes I believe in purchasing software

I want to make sure that nobody confuses my stance on package based software. I think it is a very healthy thing for organizations to buy software packages, especially in areas that the software will not provide them a competitive advantage (easy example: you will almost never get a competitive advantage out of your account process – so that is a good thing to purchase). As an industry, we need to be a little more honest with our terminology and not call it Buy versus Build, but rather Build versus Buy then Build.