The Apocalypse Plan: What to Consider before Things Go Wrong

As testers, we think about risk all the time. Yet for some reason, the business doesn’t seem to think of disaster recovery as a testing job. Sometimes, we are just the right people to plan for the worst ... and sometimes, no one else is minding the store.

Undoubtedly, your organization has disaster recovery plans in place that outline steps to take when catastrophes befall your technical infrastructure, from air conditioner units leaking into the server room to run-of-the-mill denial of service attacks. These are recoverable disasters, but the ultimate disaster is going out of business. Nobody likes to think that could happen to their current company, but the reality is that no one is completely safe, and you need a plan for this situation, too.

Perhaps the annihilation will not be total. Maybe, instead, a tech titan would buy your company and sunset your product because it competes with another offering, like Google recently did with Picasa. Or perhaps you built a product like DailyBurn Tracker, a mobile fitness tracker app whose functionality was superseded by wearable fitness trackers. In these cases, your company might go on, by your product or project would not.

The legal and ethical obligations you need to consider depend on the type of relationship you have with people who have come to depend on your software and on any contract your company has or will enter with its clients.

Thinking about your obligations to clients, users, customers, and partners before the worst happens can make the transition easier for everyone. Here are some people and things you should incorporate into your apocalypse plan.

User Data

The most casual relationship is between your organization and a person who is using your software for free after agreeing to terms and conditions. The user has uploaded content or entered information into your system, trusting that he or she could get it again when needed.

At the very least, you might want to notify your users about your company’s impending closure or change in status. This should give them a chance to retrieve their information if they want. Depending on the nature of your application, you might also want to create easy mechanisms for the users to export the information into formats other applications can consume, such as an Excel spreadsheet or the like. This last extra mile might not require writing a new set of code—you might only need to expose some internal tools or queries with clear communication that this would be without guarantee or warranty.

In addition to the user data from the application itself, your company has data on the users that it might be selling to interested third parties. Even if that wasn’t happening all along, during the final stages of liquidating a company, someone often has the idea to sell users’ information as a last action. Before you get to that point, consider whether your organization might want to do this, and write it into your terms and conditions early—or, barring that, prepare the user email that indicates the change in terms and conditions and give the users time to opt out.

Client Data

The difference between a client and a user, at least in this case, is that clients have paid you money to use your software and store their data. You will need to account for client data more carefully than user data, as dictated by contractual obligations. So before the end arrives, consider how to address the possibility of your company’s closure in your client contracts and terms of usage.

Customer Payments

As strange as it might seem to people working at early-stage startups, sometimes companies can book revenue and still fail. If your company goes pear-shaped after taking in some revenue, how will it handle payments for services that extend beyond the last day the lights are on? For businesses with recurring payments and monthly subscription models, this is easy: Just stop collecting the money when the business closes. However, if your company is going to fold in July and you’ve taken money for providing service until December, you might want to consider offering refunds—or making a run for a country without an extradition treaty.

Again, recognizing this possibility will help structure contracts to account for this case, and to ensure both you and your clients know what will happen should your firm have to close its doors.

Partners and Service Users

In addition to clients, you must assess what impact your application will have on partners and users of your software as a service. If you expose functionality via an API or for other software to consume, your partners and users will need a pretty good amount of lead time to alter their processes and code to account for the sudden black hole.

Conclusion

It’s difficult and emotional to plan for the end, and consequently it is often overlooked—in individuals’ personal lives, in the corporate world, and especially among small- and medium-sized businesses. As a tester, risk management is part of your responsibilities, so you may be just the right person to propose outlining a plan of action in case the worst happens. I hope you’ll never need to use it, but having a plan in place can remove one source of anxiety from a stressful and overwhelming situation if it ever strikes.