Buy, build or both: how to decide

Almost every technology project reaches the same question: should we buy a product, or build something of our own? The answer often comes from habit. Teams with developers tend to build; teams without them tend to buy. Both habits are expensive when they’re applied to the wrong problem. Two more answers are worth testing: both, and fixing what you already have.

Start with what the software supports.

A useful starting point is the distinction Martin Fowler drew between utility and strategic software, in a note published on 29 July 2010.¹ Utility software supports work that every company does in much the same way: payroll, accounting, document storage. Strategic software supports what sets a company apart: the way it prices, plans, serves or delivers. The same kind of technology can fall on either side. What matters is the business function behind it.

Fowler’s advice is direct. For a utility function, buy the package and adjust your business process to match the software, and avoid spending heavily on customising it. For a strategic function you don’t want the same software as your competitors, because it would take away your ability to differentiate. There the main risk is failing to act before competitors do, so speed matters and cost matters much less. He also points out that only a few projects are strategic.

Seven questions

1. How much does this process set you apart? If it’s how you win customers, owning the software can pay off. If it’s administration, it rarely does.
2. How well does the market cover it? If several products cover most of what you need, building is hard to justify. If nobody has looked, look before deciding.
3. Could you change your process to fit a product? Adopting a product’s standard way of working saves configuration, testing and upgrade effort for years.
4. Who will look after it in three years? Custom software needs an owner for its whole life: someone to fix it, update it and change it as the business moves.
5. How many systems must it exchange data with? Integration is a large part of the work whichever way you go.
6. When does it need to be in use? Products exist today. Custom software needs time, even when the first release is small.
7. Are there rules on where data is kept or how it’s processed? Strict rules can narrow the market enough to change the answer.

The costs people leave out

Buying looks cheaper than it is when the comparison stops at licences. Implementation, configuration, integration, data migration, training and process change all cost money, and annual price increases add up over five years. Leaving has a cost too: getting your data out, and moving people to something new.

Building looks cheaper than it is when the comparison stops at the first release. Software in use needs fixes, security updates, changes when the business changes, and people who understand it. When those people leave, the knowledge goes with them unless it was written down.

The fair comparison is a five-year cost for each route, with the assumptions written next to the numbers.

Often, the answer is both.

The choice is rarely all or nothing. A common pattern is an established product for the standard part, with smaller pieces of custom software at the edges: where the business really works differently, or where systems have to meet and no connector exists.

Configure the product first, and customise only where configuration can’t do the job. Heavy customisation inside a product tends to make every upgrade harder.

In ERP, the question is how much stays standard.

Where a packaged ERP is already in place, the decision to buy has been made. The open question is how much of it stays standard. SAP calls the aim a “clean core”: “keeping your ERP system as close as possible to its standard, vendor-provided state while handling custom modifications through cloud extensions and side-by-side innovations”.²

Fowler’s test works inside the ERP too. Where the work is utility, adopt the standard process. Where the business really differs, build the difference beside the core, and keep a list of every departure from standard with its reason and its owner. The next upgrade is planned from that list.

The fourth route: fixing what you have

Replacing a system is one answer. Improving the one you have is another. A product that disappoints may be poorly configured, a version or two behind, fed with poor data, or used by people who were never trained on it. Each of those can be fixed without replacing the product.

Fixing stops being the right answer when the vendor is ending support, when the product can’t do what the business now needs, or when keeping it running costs more than moving. Put the fix on the same five-year basis as the other routes.

Write the decision down.

Whatever you decide, record the options considered, the criteria, the evidence, the risks and when the decision should be reviewed. A one-page decision memo is cheap to produce, and it stops the same argument from starting again six months later.