The Builds That Did Not Win

One of the things I distrust in business books is the extraordinary success rate of their authors. Every experiment seems to become a case study. Every setback turns out, conveniently, to have been the exact lesson required for the next triumph. Real work is messier.

I built a restaurant-bookings solution. It was perhaps seventy percent complete and I am confident I could have finished it. The business chose an established product instead and was prepared to pay for it.

The business already had confidence in the established supplier, including a relationship at senior level. That was part of the context in which the decision was being made. An internal build and an established product bring different questions about support, ownership and confidence, as well as features. Experience gave me a more useful question than how to defend our version, what outcome do we actually want?

So I stopped building.

Then I challenged the supplier instead. I pushed them on whether AI could answer the phone and book the table, rather than simply digitising the existing journey. They are now developing in that direction. I pushed on price too. If somebody else is going to provide the solution, they can at least be made to provide a better one.

The unfinished code still exists and may serve somebody else one day. Or it may not. That does not make the effort wasted. It taught me what mattered in the workflow and made me a more informed buyer.

Not every successful build becomes an adopted product. Not every abandoned build is a failure. The useful question is whether you learned cheaply enough.

A small experiment that stops a much larger bad investment isn’t a failed project. It may be one of the highest-return decisions you make.

Stopping the bookings build was harder than the tidy version of the story makes it sound. By seventy percent complete you have enough invested to feel ownership. You can see the finish line. You can also start constructing very persuasive reasons why everybody else should let you cross it. That is exactly when sunk cost begins dressing itself up as conviction.

That experience changed how I think about ownership of ideas. The internal build does not have to win for the approach to have worked. Sometimes its job is to make you a better buyer. Sometimes it gives you the evidence to negotiate harder. Sometimes the prototype exists mainly to show a supplier what good could look like. If the business ends up with a better outcome, I am increasingly relaxed about whose logo appears in the corner.

Pulse, a tool I built for weekly manager check-ins, taught a different lesson. It was not rejected. It simply did not deserve daily attention. That matters because adoption is not binary. A tool can be valuable occasionally. The mistake would have been inventing reasons for people to use it more often just so the usage chart looked healthier. It sits there, quiet, until the question it answers becomes useful again. I rather like that. Not every tool needs to become a habit to justify having existed.