Lesson: Shuttering a Service
I recently shut down simplehoney's free wishlist service and mobile app. I tried my best to get word out that the service was going down. However, a month after taking the servers offline, users continue to send us messages trying to get their wishlists to load or find out what happened to their data long after we took down the servers. As CTO and co-founder I wish I had handled it better.
If you ever find yourself in a position where you are deciding to shutter your service, be it an acquisition or simply because you decide it's time to take the service down, here are some tips:
Host a static copy of your site
For all public facing data you should generate a static version of the content. This allows users to access their content long after your service is taken down, but without the need to keep an entire infrastructure online.
I suggest using Jekyll to create versions of your website that can work as simple static files.
For us, we ratcheted down our services from larger Amazon instances to smaller instances over time. However, a static site could be hosted on small instances and minimal hardware (I am a big fan of Joyent micro instances, they can serve many thousands of pages an hour).
Basic steps for generating a static site:
- Generate a sitemap of all public facing pages
- Start a fork of your code base and modify your presentation and navigation code so that the site works as a series of html files
- Traverse your sitemap and pipe the urls to curl or wget to generate the static pages.
- Store all images on a small or singular instance machine. Try to keep file hierarchy to one or two folders deep.
- Install caching using Varnish to prevent an unexpected surge in traffic
Try to be Self sustaining
If you've built a consumer site, hosting static files gives you a secondary benefit by allowing the site to continue generating affiliate or ad revenues. This can hopefully allow generating enough revenue to keep the minimal site running.
Backup user data
For each user in your database, export all their data in a simple format (JSON). Zip it up and store it securely for the duration of the holding period.
Try to host the data for more than 60-90 days
Once the service is switched to static files, you can host it for a fairly long time.
In 6 months or so, the site will generate little to no traffic and you can finally switch the server off.
If your product is cyclical, then try to hang around for at least a one full year cycle.
Having launched on Black Friday last year many of our users will begin contacting us trying to gain access to their wishlists.
Clean up the database
Once all user data has been exported and prepared for the users, you should delete and destroy all user identification, personal information, and data that is tied to a user's identity.The remaining data could then be used for postmortem analysis and might even become the basis for a new idea.
Final thoughts
As founders I hope you learn from my lesson and err on the side of the helping the user access their data.
We had over a million products in our database, tens of thousands of searches, and hundreds of thousands of products wished for.
It was a a lot of fun to build, and I hope people give me another chance to build stuff they love.
Have you ever shut down a SaaS or consumer product? How did it go? Is it still running?