Build vs Buy

For years, the advice has been fairly consistent:
Buy an existing product before building your own.

In many situations that’s exactly the right approach.

However, we’ve experienced organisations opting for an existing product, fully aware that it wasn’t a perfect fit, simply because the cost, time and risk of developing a bespoke solution made this compromise an option. It’s a decision that may solve today’s problems and meet today’s requirements, but it’s a decision that leaves the product’s ability to meet future requirements dependent on the vendor’s roadmap rather than the organisation’s priorities.

Even when they choose to buy, it doesn’t always eliminate the need to build software. Organisations often end up developing custom code inside (or alongside) a proprietary product to make it meet their needs.

In the worst cases, the only practical option is to change the business processes to fall in line with the software product, regardless of whether those changes make sense.

Basically, the tail is wagging the dog.

The trade-off becomes much more problematic when operational processes are complex or highly specialised. A recent customer project we delivered (for Company A) illustrated that perfectly. Company A approached us wanting to replace a paper-based operational process that had evolved over more than 25 years.

The starting assumption was simple:
There must be an existing product that does this.

As we worked through requirements discovery, it became clear that the workflow itself wasn’t the challenge. It was the hundreds of complex business rules, approvals and exceptions that had accumulated over decades. An existing product may have handled many of them, but only by forcing the business to bend its processes to the product’s will.

Not that long ago, accepting some compromise was often the commercially sensible decision because the cost of delivering a bespoke solution was hard to justify.

Today, AI-assisted software delivery is changing that equation. Much of the work involved in discovery, prototyping, development, testing and documentation can now be completed far more efficiently. But writing code hasn’t suddenly become trivial. Instead, we’re able to spend less time on repetitive work and more time working alongside customers to understand their business and shape the right solution.

Gaining that clearer, deeper understanding with Company A allowed us to design and build a product that complemented the way the customer worked, rather than the other way round. It gave us the freedom to improve the process itself by embedding accountability into the way people worked. The result wasn’t simply a digital version of the old process—it met all the requirements, provided efficiencies in many areas and, best of all, gave users confidence.  They loved it!

Organisations can now achieve far more with the same investment. The changing economics of software delivery provides more freedom to solve the problems, innovate where it matters and move beyond simply accepting the ‘closest fit’.

None of this changes the fact that buying will often remain the right decision. But when the way a business works is part of the problem you’re trying to solve, the build versus buy decision is no longer as clear-cut as it once was.

—

*All images generated by the author using AI.