Build vs Buy: When Custom Software Is Worth It

Start by assuming you should buy

It may be strange to hear from a company that builds software, but most of the time you should not build it. If a product already does the job, it will be cheaper, available today, and maintained by someone else.

Custom software earns its place in a narrower set of situations. The skill is in recognising them.

Signs you have outgrown off-the-shelf

• Your team works around the tool. Spreadsheets on the side, data copied between systems by hand, a "how we really do it" document.
• You pay for ten features to use two — and the price rises with every seat.
• The thing that makes you different is the thing the tool cannot do. Software everyone can buy cannot be a competitive advantage.
• You need systems to talk to each other and the integration does not exist.
• The software is the product. If you are selling it, you have to own it.

One of these is a nuisance. Three is a pattern.

The real cost of each

Comparing a monthly subscription to a development quote is not a fair comparison. Look at both over three years.

Buying costs:

• Licences, which usually scale with users
• Integration and configuration work
• Staff time lost to workarounds
• Migration cost if the vendor changes pricing, direction or ownership

Building costs:

• Design and development
• Hosting and monitoring
• Maintenance: security updates, dependency upgrades, small changes
• Your own time making decisions — more than people expect

Building has a large cost up front and a smaller one afterwards. Buying is the reverse. Where the lines cross depends on how many people use the system and how badly the existing tools fit.

The option between the two

It does not have to be all or nothing.

• Extend what you have. Many platforms have APIs. A small custom tool that sits beside a bought product is often the best value in software.
• Build only the part that is unique. Use off-the-shelf billing, authentication and email; build the workflow that is specific to your business.
• Start small. A tightly scoped first version proves the idea before the larger investment. We have written about how to scope an MVP for exactly this reason.

A short decision checklist

1. Does a product exist that does at least most of what we need?
2. What does the gap cost us each month, in money and in people's time?
3. Is this capability something our customers choose us for?
4. Who will own the system in three years?
5. What happens if the vendor shuts down or doubles the price?

If the first answer is yes and the third is no, buy it. If the gap is expensive and the capability is central to the business, it is time to talk about custom software development.

We apply the same test to ourselves. The products we build and run exist because the tools we tried did not fit how an agency actually works — and everything else we use, we buy.