Build or buy? A decision framework that does not end in regret

The question is asked too late

By the time most organisations ask us whether to build or buy, they have usually already leaned one way. Either a supplier has demonstrated a product and the discussion is about how to fill its gaps, or someone internal has decided that nothing available fits and the discussion is about who builds it. Both starting points skip the analysis that actually determines the outcome.

Here is a framework for making the decision deliberately.

Start by separating the process from the requirement

Write down what the system must achieve, in business terms, without reference to how you currently do it. “Applications are assessed against eligibility criteria and a decision is recorded” is a requirement. “The form is printed, signed by two officers and filed by reference number” is a process. Products will meet requirements; they will rarely match processes. Knowing which of your process steps exist for a good reason and which are historical accident is most of the work.

The case for buying

Buy when a mature product covers your genuine requirements at acceptable cost. You will get more functionality than you could afford to build, delivered faster, maintained by someone else, improved continuously and supported by a community of other users. For anything that is not a source of competitive advantage, such as accounting, payroll, email, HR records and general CRM, buying is almost always correct.

The costs people underestimate: configuration and data migration effort, integration with your other systems, annual licence increases, and the cost of the compromises the product forces on your process.

The case for building

Build when the process is genuinely a differentiator, when the available products force compromises that damage the business, when integration requirements are unusual, or when licence costs at your scale exceed what development and maintenance would cost. Custom software gives you an exact fit, complete control, no per-user licence escalation and the ability to change direction when the business does.

The costs people underestimate: ongoing maintenance and security updates, which do not stop when the project ends; the dependency on whoever built it; and the fact that you now own the roadmap, including the parts you have not thought of yet.

Five questions that usually settle it

1. Is this how we compete? If a competitor could buy the same product and match you, the process is not a differentiator. Buy it.
2. How much of our requirement does the best available product actually meet? Above roughly eighty per cent, buying and adapting is usually right. Below sixty, building deserves serious consideration. Between the two, look hard at whether the missing twenty per cent matters.
3. What does the compromise cost? Quantify it. If the product cannot do something and the workaround costs two staff days a month, that is a real number you can compare against development cost.
4. What is the ten-year cost of each option? Licences compound. So does maintenance. Compare like with like over a realistic horizon, not first-year cost.
5. Who maintains it in three years? If the honest answer for a custom build is that you are not sure, that is a strong argument for buying, or for building only with a supplier who will hand over documented, maintainable code.

The option people forget

The choice is rarely binary. Buying a strong core product and building the specific piece that differentiates you, connected by a well-designed integration, is frequently the best answer. You get maintained infrastructure for the commodity parts and an exact fit where it matters. It requires integration capability, which is precisely why organisations without it default to one extreme or the other.

A note on advice

Be careful whose advice you take. A firm that only builds custom software will find reasons to build. A reseller will find reasons to buy the product they resell. Ask any adviser what they would recommend if they were not involved in the delivery, and take the answer seriously.

We build custom software and we also implement off-the-shelf platforms, which means we can afford to be indifferent about which you choose. If you are weighing a decision like this, we are happy to talk it through before anyone writes a proposal.