We built it, then told them not to use it

A client had a regulatory requirement to handle at checkout: certain orders needed to behave differently depending on where the customer was. We scoped it, built a checkout extension to do exactly that, and tested it properly. Seventy-seven live test runs, zero errors. It worked.

What we did

Then we told them not to use it.

Somewhere in the testing it became clear there was a simpler operational route to the same outcome, one that did not need a piece of custom code sitting in the checkout at all. It was less for the client to maintain, less that could break, and it solved the actual problem just as well. So we recommended that instead, and parked our finished extension as a tested fallback in case the simpler route ever stopped being enough.

The result

The client got the outcome they needed by the least complicated path, and a proven backup they can switch on in minutes if circumstances change. We had already done the work either way. Recommending against using it was the right call regardless of that.

What to take from it

The person building something is rarely the one who will say “you might not need this”. It is worth working with people who will tell you the simpler answer even when they have already built the complicated one. The build is not the point. The outcome is, and the cheapest outcome that holds up is almost always the right one.