There are thousands of t-shirt businesses, yet Life is Good has found a way to differentiate from the pack and pull away with a product line which has cult like loyalty. In a true testament to good story telling, founding brothers Bert and John Jacobs founded Life is Good on the principle of simple optimism. Since 1994, the company has stayed loyal to their roots of optimism, good-will and humility, while doing so they’ve pulled in over $80 million dollars. Not too bad for two brothers, a simple idea and an unwavering vision.

This is the first of a new series of blog post we will be doing called “Learning from Failures”. The theme of this series is to help guide others on what not to do; to avoid making the same mistakes twice. I’ve found plenty of information on the subjects of what to-do, and often that type of advice is hypothetical. This advice is from experience that has been learned the hard-way.

On to the subject, transitioning sites. A few months back we were approached by Client X to start maintaining their PHP website, taking over all creative and technical aspects of the project. Our work would be contracted under an hourly retainer which provides the client with priority service at a discounted rate. Retainers are great for clients who are working with us for a preset amount of hours per month. Usually, we reserve retainers for clients whom we’ve recently completed a redesign for. This way they have additional hours to make upgrades and alterations to the site, post launch.

In the case of Client X, the retainer proposal had an added incentive; Imulus will host Client X’s site as part of the retainer. At the time of the proposal this didn’t seem like a huge risk, however it was a big mistake. Rather then leave the site where it was, we transfered the site to our servers without doing extensive due diligence.

Client X’s site was not very complex, at least not at first glance. The plan was to download the site; set it up on our live box and then switch the DNS at the time we felt the site was ready to go live. Once the client provided us with FTP access we downloaded the code to see if there was anything unusual. We looked for include files, we browsed through javascript and we looked at how the pages were assembled. There was no database or integration points to be found. The site ran fine on our dev box within 2-3 hours of setting up the site, with the exception of the lead generation forms.

Since the site ran fine, and the code looked fairly standard, we decided to send the proposal for approval. We wrote off the lead generation form problems to the fact we haven’t yet switched the DNS over to our live server.

Client X warned us that the lead generation forms were more intricate then we expected. Rather then asking additional questions we assumed that a simple lead generation form couldn’t be that complex. Nobody would code a web form in a way which we’ve never seen in the 12+ years we’ve been doing this work. Upon closer examination what seemed like 2 very simple lead generation forms with Salesforce integration was actually several forms all passing divergent data throughout the site via a free third-party content management system. Even better, the content management system was no longer supported or available for re-installation. We now had a problem!

Once the DNS switch was made, and the site was live, warts and all. We had to rally to repair the problem ASAP. The client called every few hours to get an update and to ask why this had happened. We did our best to explain the problem and take ownership of the mistake, yet the site was still broken. Our team worked quickly to build an alternative to the missing content management system which would produce the same results as the system it replaced. Eventually, after an agonizing week of eating crow and pulling our hair out, the site was working fine.

Ultimately we voluntarily ate the hours on the project and decided to chalk it up as a valuable lesson on what not to do.

What did we learn from this failure?

• Don’t assume anything.
• If a client offers up recommendations or pointers into their existing website, ask more questions!
• If you can’t get all the information about an existing website that you need to transfer, then do the transfer on an hourly, not project basis. If you can’t do any of those things then walk!
• Invest the time and energy in making sure a site is working 100% tested before flipping the DNS switch.
• ALWAYS own up to your mistakes!

In case you are wondering, Client X is still a client of ours and we’ve been happily working on their projects ever since the mishap.