Subscribe via RSS Feed

Buying vs. building software applications: the eternal dilemma

August 12, 2013 3 Comments

Some years back, an IT colleague of mine mentioned a conflict at a corporation where he was working at the time. The corporation had a mission-critical application deployed across a large number of workstations. The corporate employees who used this application largely used it and nothing else all day long at dedicated workstations. The application they were using was a customized third-party application; however, the firm had been having chronic problems with this app (let’s call it “QRSApp”), and so was 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 wanted 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 was 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 several million dollars at the very least. 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.

[Adapted from an article originally written for the online version of Baseline.]

About the Author:

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at

Comments (3)

Trackback URL | Comments RSS Feed

  1. Geoff says:

    Another great article, Bruce! I’d be interested to get your opinion on the degree of customisation that COTS packages can realistically handle. I’ve seen several systems that started out as customised COTS, but eventually departed so far from the vanilla functionality that we were writing “business rules” that simply bypassed the built-in processes and called out to a custom java function. At this point, you’ve got all the downsides of creating and maintaining your own code, *plus* the hassle of fighting against the package framework, reworking the customisation every time a new version is released, etc – clearly not optimal. The sad thing is that this isn’t rare: the alternative is to change the business to fit the package, which might be a great idea, but it’s much more difficult to persuade the business to change than to sign-off a huge, doomed software integration programme. So in your experience, how much customisation is too much?

  2. bfwebster says:


    Yeah, that’s the real question, and a good enough one that I’m going to tackle it in a separate post; I’ll quote your comment over there. ..bruce..

Leave a Reply

You must be logged in to post a comment.