It may sound like a joke, but despite the strangeness of this post title, it’s actually a pretty serious matter, at least for us freelancers.
Think about all the clients that depend on you for hosting their website. They probably don’t have a clue about how to manage their domain name, or what is a domain name in the first place. They don’t know where their data, images and documents are stored exactly. Chances are they don’t care. They don’t care because they know that you are the one who tie all the components together and make it all work. So they want you to be in charge of everything: the domain, the hosting, the database, the backups, etc. They also don’t care whether or not you use 3rd party services like Amazon AWS, Mailgun, Mailchimp, Pusher, Zoho Mail or Google Apps.

Then one day you walk on the street, joyfully tweeting like a little bird, when suddenly the lightning strikes you right on the head, abruptly ending your tweeting and your life at the same time.

As your loved ones mourn your departure and try not falling into deep depression, the telephone rings. Your wife picks it up.

– Hello?
– Ehm, Hello. Can I speak to Robert?
– I’m afraid it won’t be possible. Robert is dead.
– Oh my God… I’m so sorry. I’m guessing he is not in a position to fix the issue with my website then? The domain has expired and no one can access it anymore!
– Well, no, he won’t be able to help you. You know, he is busy being dead and all this kind of stuff.
– Oh I so much understand. But who can help me with my website then? Do you know how to renew my domain?
– What is a domain?
– I think it is the thing that ends with .com
– Oh, I don’t know how it works. I can have a look at his computer and try to help you but I’m not sure I will be able to fix the problem for you.
– …
– …

Do you want your wife, your husband, your kids or anyone else to ever have to deal with this kind of stuff? Unless you were a very bad person when you were alive, your loved ones will have a hard time accepting that you are gone. The thought of seeing them struggle to help your former clients during these hard moments is not very pleasing, isn’t it?

Companies don’t have this problem. In a company, there are obviously more than one person and the possibility that everyone die or become invalid at the very same time is unlikely. The freelancer on the other hand is all alone. All the knowledge needed to run his business resides in his brain and in the various online services that he alone knows how to access. He alone knows what vital information each of them contain. If the freelancer disappear, this knowledge is gone for good.

Ponder this for a second:
1. You are dead.
2. Your former clients are left in the dark.
3. Your family might have to clean up the mess for you.
Three strikes. Everybody loses. Not cool.

I was obsessed with this thought until I decided to do something about it. I didn’t want to write some kind of “technical sheet”, hand it to a loved one and explain them how it works so that they know what to do if something bad happens to me. It is still asking too much of them. If I had to unexpectedly depart, I don’t want to bother my loved ones with things like that.

What am I to do then?
The idea I came up with is to prepare an emergency procedure for each of my clients. I won’t go into technical details here. My objective is to discuss the idea of an emergency procedure and perhaps encourage people to think about it. Let’s think for a second about the knowledge and data that must be transmitted to the client if death pays me a visit:
1. Domain name
2. Source code
3. Database
4. Other documents (images, videos, text, etc) that may be stored on the server’s file system or on a 3rd party service like Amazon AWS
5. All 3rd party logins, passwords and api keys (Think about services like Amazon AWS, Zoho mail, SmugMug, etc)
6. A message to instruct the client what to do

Before I describe each of these steps, the very first thing to do is to create an emergency email inbox for your client. You can use an online email service like GMail or hotmail, it doesn’t matter. You will soon see how this inbox will be used.

1. Control over the domain name

If you use a registrar like Namecheap or GoDaddy, you can easily grant accesses to other people for each of the domains you have registered. The thing is, the client will need to have a GoDaddy or Namecheap account to manage their domain name. Personally I am not very fond on the idea of bothering my clients up front with technicalities like this. If I register a new account on Namecheap using the email of my client, they will start receiving emails and wonder what this is all about. That’s the main reason for creating an emergency inbox for your client (e.g. [email protected]). Then you use this address to register a new account on Namecheap/GoDaddy/Other. Finally, using your own account, you grant full access over the domain name to the newly created account.

2. Control over the source code

If you host your source code on Github or Bitbucket, you simply have to do the same thing you did for the domain name. You go to the repository settings and you give access to your client (always using our emergency email address). I think a read-only access is enough in this case. The future commits on this repository should be made on a new user account anyway.

3. Control over the database

This one might be trickier. Unlike the Domain name or the source code, there is no online service that will do everything for you. You have to find a way to either A) send the most recent backup or B) create a SQL dump on the spot. I prefer the second option. A nice way to tackle this is to create a new route on your client website to actually download the database. Example: mysuperwebsite.com/SOMEUNIQUEID. Of course, the access to this URL needs to be protected. After successfully authenticating, the client clicks on a button which will trigger a shell script that dumps the database, gzip the content and sends the file back to your client.
You will want to be extra careful and make sure that the code you write for this is rock solid. If it fails, your client might have no other way to recover its data. I would personally set up a script that runs periodically to make sure that everything functions properly.

4. Other documents

Perhaps your client’s website allow users (or administrators) to upload their own documents? If these documents are stored on a 3rd party cloud platform like Amazon S3, the client needs an access to its bucket. This means you need to create an Amazon S3 account on their behalf (like we did for the domain and the source code). You can then share the S3 bucket with the client using bucket policies or ACL. Really soon though the client will need to have a bucket on its own account and import the data in it because, one day or the other, I guess Amazon terminates the account of deceased people as they have a tendency of not paying their bills. This is something that the new developer(s) who will replace you should be able to figure out on their own. If they don’t and the bucket becomes unusable after awhile… well they’ll have to deal with the Amazon support. Hey it’s not like we didn’t do our part already!
If website documents are stored on your server file system, your need to find a way to send these to the client upon request. I think the solution discussed concerning the database (above) could be used for downloading the documents as well.

5. 3rd party services

We need to make sure that all online services used by the website (if any) can be managed by the client. The procedure will depend on each 3rd party service but generally, it will be a matter of creating the accounts using the emergency email address.

6. Write a simple how-to message

The last thing we should do is writing a message to the client explaining them what to do in case you (the freelancer) becomes physically unable to manage the website anymore. But here is the good part, there is no need to be all technical about it. Your client will have to find another developer / team to take care of the website, so in actual truth our how-to message is for them. It’s fair to assume that THEY will know how Amazon S3 works or how to restore a Postgres SQL dump. Our part is only to transfer them the data and knowledge required to make the website function correctly.
Our how-to message could look more or less like this:

Hello Client Name,
Here is all the required information you will need in case I become physically unable to take care of your website (death, accident). Once you found someone else to replace me, I suggest that you forward this current message to them.
1. Technologies used
Server side programming language: Ruby On Rails
Database : Postgresql
Client side tools used: CSS3, HTML5, Javascript
2. Download your database
To download your database, go to the following url: —————- and enter this password: ———–
3. Get your copy of the source code
The repository is hosted on ——-. You can access it by logging in using the following credentials: ——
4.
….
Sincerely,
Your name

This message should be sent to the emergency email address that we have created earlier. Finally we send a message to our client using their current email address, instructing them that we have created an emergency procedure. We give them the login info to access their emergency inbox, encouraging them to write it down on a sheet of paper and store it in a safe place.

I like this idea because you don’t scare your clients up front about the technical aspects. You simply let them know that such a procedure exist and how they can access it in case something goes terribly wrong.

Having such a procedure will give some peace of mind to everyone: You, your client and your loved ones. I’d love to read what you think about it. Your comments are appreciated!