What happens when you’ve invested a lot of money into a project, only to discover that you’re deep into a money pit?
Recently, we came upon just such a scenario when we performed a site audit for a new client. Several of our senior developers commented that it was one of the most problematic builds they had seen in their 30+ years of combined experience. This was the third generation of the app, and the client came in complaining only of performance issues.
The client was, understandably, horrified and shocked at the news. After spending so much money and time building this app, it was extremely difficult to hear that we recommended that it be taken down immediately.
In this situation, we offered our client a choice. Rebuild the app from scratch with us, or go to another firm.
Already Gone Bad
Normally when we perform a site audit, our findings are not so severe. When things are bad we usually end up offering our clients a choice between completely rebuilding and performing targeted fixes on the existing site. Many times, we find that the client wants to try and fix the existing site, despite our warnings that doing so will almost certainly be more expensive in the long run.
This is what’s known as the Sunk Cost Fallacy, a psychological phenomenon that occurs when someone refuses to give up on something because they’ve ‘already spent so much effort’ or ‘already done so much.’
The Sunk Cost Fallacy is especially prominent in situations where a group has already committed great resources. It is also dangerous because, as we have seen time and time again, rescue sites tend to have problems that stick around the code like tuberculosis. These issues remain silent for quite some time after the initial problems are fixed, only to rear up and cause havoc when least expected.
There are many groups in the tech industry who won’t touch rescues for this very reason. Unless you built it yourself or the site is extremely well documented, it’s almost impossible to find every single thing wrong during a rescue. And of course, since a rescue is a rescue for a reason, they don’t tend to be well documented either.
Why Save a Sunk Ship?
Despite offering rebuilds to several clients, not one has decided to start over. So far, everyone has turned the rebuild down to try and save the existing site. Every time, this decision has ended up costing the client more to fix what’s already there than to scrap everything and start over.
The Sunk Cost Fallacy is difficult to beat. Scrapping all of your work and starting over feels like failure, and it sounds expensive. It feels risky to rebuild. How do you know that the rebuild will be any better than the original? How can you justify spending more money on top of what’s already been spent for the exact same thing?
But there’s the fallacy. A rebuild isn’t the same thing. A rebuild of a site works as expected, is well documented, is as easy to use as we can make it, and adheres to the strictest security and accessibility standards in the business.
When you commit a sizable budget to your web project, put yourselves in the hands of experts who know all the Drupal shortcuts that shouldn’t be taken, all the loopholes that should be closed, and how to make it obvious why certain decisions were made to ensure that future developers have no problem understanding exactly what happened. Otherwise, you may find yourself deep into a very painful hole.