Buy vs. Build Software Applications: The Eternal Dilemma

By Bruce F. Webster  |  Posted 2008-08-27

The other day, an IT colleague of mine mentioned a conflict at a corporation where he’s working. The corporation has a mission-critical application deployed across a large number of workstations. The set of corporate employees who use this application largely use it and nothing else all day long at dedicated workstations. The application they are using is a customized third-party application; however, the firm has been having chronic problems with this app (let’s call it “QRSApp”), and so is looking at different solutions. The firm could continue to make changes to QRSApp to fix their problems. The firm could switch to a different third-party application; several other vendors market applications of this type within this firm’s industry. Or, as a senior IT manager now wants to do, the firm could develop a completely custom and private application to replace QRSApp, so that the firm has complete control over it.

The question: which solution is best?

Let’s step back a moment to look at the issues involved. Consider the following (simplified) diagram:

A given piece of software can range from being an unmodified, commercial off-the-shelf (COTS) software package – such as, say, Microsoft Word – to being a completely custom, written-from-scratch program. Between those two extremes you can find customized and/or configured COTS software, custom software built using commercial software frameworks and libraries, and complex systems comprising all of the above.

As shown above, this low-to-high customization axis usually correlates directly to three other aspects: cost, suitability, and time to deployment. First, acquisition and deployment of COTS software is usually cheaper than development and deployment of equivalent custom software. You can buy a copy of MS Word for a few hundred dollars, while developing a word processor from scratch would probably cost you a few million dollars. Likewise you’ll have to invest the time and personnel in maintaining and updating your custom software, whereas COTS software will be maintained by the vendor (though you will typically have to pay for upgrades after some point).

Second, a given COTS software package, even customized, is probably less suited to your firm’s specific needs and challenges than a custom program designed and developed from scratch – assuming that you can even find a COTS package that can be customized to meet those needs. So, if your firm needs to gather and monitor data from a complex industrial process in order to control other equipment, you may have a hard time finding a COTS package that can do what you need without a lot of customization; even then, it might not work as well as you’d like. To a large extent, your firm will have to adapt around the COTS package and the way it does things. But if you develop software from scratch, you can ensure that it does exactly what’s needed.

Third, a given COTS software package can usually be acquired and deployed almost immediately. If customization of the COTS package is required, it will take longer, depending upon the amount of customization required. But a software system built from scratch will almost certainly take much longer than any other solution.

So, now let’s get back to the original question: which solution is best? Buy or build? Well, clearly you may be compelled to adopt a particular solution by the factors cited above, namely cost, suitability, and time to deployment. And, of course, you may have situations where no commercial software is available, and so you have no choice but to build. But if you truly have a choice – as in the situation described at the start of this column – there’s a very useful rule of thumb that’s based on your business situation:

• Buy if the system is a fundamental requirement of doing business.

• Build if the system will give you an advantage over your competitors.

Think about it. Whatever line of business your firm is in, there is a basic set of IT capabilities you’re going to need. This includes standard desktop productivity applications, financial apps, operating systems, system administration software, development tools, and so on. It may even include software specific to your line of business. It really makes no sense to build any of these for your firm; instead, buy the COTS packages that best meet your needs and budget, and adapt yourself to that software; spending the time and money for custom versions just doesn’t make sense.

On the other hand, there are aspects of your business where you have the possibility of gaining an advantage over your competitors. It may be a customer-facing system where you want the ability to rapidly introduce new products and capabilities; it may be a critical chemical process; it may be a complex set of transactions involving various financial instruments. Those are situations where it may well be worth the investment in time and money to craft a custom or semi-custom solution. It also ensures that your competition can’t just go out and buy the same software; they’ll have to build their own and will likely lag behind you.

So, what about the scenario given at the start of this column? What should the corporation do? The answer is probably “buy” – they should go out and buy the best-of-breed commercial application that’s equivalent to QRSApp, possibly with some customizations. This is a better solution than developing their own private QRSApp equivalent from scratch; the time, money and IT resources should instead be spent on custom systems that given the corporation a competitive edge.

Something to keep in mind.

Bruce F. Webster is a consultant specializing in reviewing and rescuing large-scale IT projects. You can reach him at or via his websites at and  [© 2008 by Bruce F. Webster]