Software: Build or Buy?


A conventional wisdom in IT is 'everybody knows you don't build software any more'. But some conventional wisdoms are actually wrong. We would like to put this one to the test. To do so we will consider the advantages and disadvantages of custom and packaged software in relation to the key decision points.

Differentiate or standardise

This is a crucial factor – whether the objective of the project is to differentiate or standardise the aspect of the organisation which is under review.

If you are launching a new product or service you are presumably striving for something unique. To gain a competitive advantage, the core business process needs to be different and the organisation requires freedom to engage in continuing business improvement, and to embark on major and rapid change.

Accordingly, software used in the core business area needs to be controlled by the organisation and sustain the differences in the business. Using a package as the support system is by definition standard, duplicable and outside the control of the organisation. Packages therefore present some risks where a project takes on a strategic significance.

On the other hand, if you are looking to improve a non-core function, such as inventory management, or possibly agenda management, you may want to standardise. As long as a suitable package exists, there is little to be gained by embarking on a software development. It may even be advisable to adapt work practises if necessary. The economy of scale offered by packages can drive standard costs down.


The cost of developing custom software is made up almost entirely of time costs. The following chart shows the costs involved.

In a package implementation the following time costs are involved.

Time savings in package implementations stem from the fact that less development is involved and testing is less onerous as a consequence. As a rule of thumb development projects require almost twice as many hours as package implementations.

Offsetting this are the licence fees charged by package vendors (custom software is free of royalties). The number of users to be licensed is likely to determine which option is more economical – the less users, the more likely it is that packaged software will be more economical.

Lead time

If you have chosen a package which requires no alteration, the lead-time for implementing a package is about half that of developing a system. This is a simple reflection of the fact that half the number of hours is involved.

The gap closes the more package alterations are required.


Nature of riskHow to solve with custom softwareHow to solve with package
Cost overruns and delaysTight specifications and tight contractsTight specifications and tight contracts
BugsFormal acceptance criteria and warranty provisionsChoose a popular package
Software does not complyTight specifications and tight contractsTight specifications and tight contracts
SupportCreate technical documentation for others to follow and use a popular platformChoose a popular package and a reputable dealer
AvailabilityIn principle this problem does not apply to custom software as long as there are developers to be foundIf the packages do not closely match your requirements you're going to have to build something


The decision between custom and packaged software is not always clear-cut. Packages address standard functions such as document management, accounting, distribution, inventory and HR. Custom software comes to the fore when you are looking for a strategic gain or operate in a manner which is not catered for by the packages. As usual, it's horses for courses.

May 2005