Prove Before You Buy

I used to be quite good at buying software. I could run a procurement process, compare vendors, negotiate a contract and land a platform. For years that was a perfectly sensible technology skill.

These days, I’m much more annoying to sell software to.

The change is not that I now think vendors are bad. I do not. The change is that I want the problem to earn the purchase before the purchase earns a project plan.

A central operations team once came to me because a software service they relied on might have to be removed. A couple of people asked a wonderfully simple question, could we do something really lightweight with AI instead?

The service cost roughly £4,500 a month. The first internal version took around a fortnight to build. That sentence is the dangerous one, because it is very easy to tell the story as though two weeks later everybody high-fived and cancelled the contract. That is not what happened.

I spent weeks testing and refining it with the people who would actually use it. I put it into a small number of restaurants and watched what happened. I changed things because the stores told me where my assumptions were wrong. Only when it had survived contact with real operations did it roll across the multi-site business, with minimal training delivered over Teams. From first conversation to full rollout was about eight weeks. The first fortnight proved I could make something. The following weeks proved whether I should. A prototype is a cheaper way of discovering what the final answer needs to be, and those weeks with the stores were where that discovery happened.

The result became TableTalk. It costs a few pounds a month to run across the estate rather than thousands each month, and it has since collected more than 15,000 pieces of guest feedback. It saves comfortably above £50,000 a year in avoided subscription costs.

It is tempting to stop the story there because that is the bit that makes a nice slide. But there was something the old platform did that my replacement did not. It provided the executive team with a monthly view of how the wider industry was performing. I could not recreate that honestly from the data of one brand.

So I asked a couple of executives what they actually did with that information. The answer was essentially that they talked about it for a couple of minutes. No decision. No action. No operational change.

Feature comparisons give us something tidy to count, but asking what people actually do with a feature tells us rather more. That is an uncomfortable but useful value test. A feature can be real, polished and genuinely unavailable in your replacement and still not be worth £4,500 a month.

This is why I no longer like the phrase “replace before you buy” quite as literally as I once did. The better discipline is to prove before you buy. Sometimes the proof shows that a tiny internal intervention is enough. Sometimes it shows that the expensive platform is absolutely the right answer. Either way, you have learned before you committed.

This is not about finding the cheapest answer. It is about finding the cheapest responsible way to discover the right answer.

None of this means the next answer should always be an internal build. There are days when I would happily pay a supplier to take a complicated problem away from me and answer the phone when it goes wrong. The change is that I now want to know what I am paying them to remove. If the value is genuine, pay it. If the value is mostly habit, polish or a report everybody glances at before moving to the next agenda item, then perhaps the problem has not earned the invoice yet.