Planning for closure

When starting work on a new website few of us think about how long the site should last for. I know I don’t. But I think we should.

The lives of many websites have, or will have, an end, but we tend not to think about them in advance. Often, the end is unplanned. Websites sidle slowly into neglect, gradually falling apart. Or they blink out of existence when the domain isn’t renewed or a credit card expires.

How long do you expect your websites to be online for? The answer has implications for your time and, if applicable, your client’s time and budget. Below are four questions I think it’s worth asking before starting work on a new website.

1. How long do I expect this site to stay online for?

This is the basic question that rarely gets asked. We’re so focused on getting the site live that we don’t think about when its death will be. Perhaps more fundamental is to ask “Is this site going to live forever, or will it close at some point?”

Obviously, “forever” is unlikely, but often we aim to keep a site alive for as long as possible. My personal site, for example, has no fixed end date. Quite how to keep a website alive for whatever-forever-means is worthy of another post full of different questions.

Sometimes there is no clear answer. The website for a company is unlikely to last “forever” but also has no specific end date. It will probably last for “a while” until the company outgrows it, or the brand changes, or it looks old-fashioned. But it’s worth at least having a guess. Might that be in six months? Or five years?

The duration of your site’s life has implications for you, your client and their budget, so it’s worth trying to pin down. If you can’t, fair enough — but at least have everyone acknowledge you’re making something whose future is entirely undecided. The remaining questions are still relevant.

2. Under what circumstances will the site close?

If you’ve decided the site has a finite lifespan, when does its life end, and why? If the site is for a particular event maybe you (or your client) have decided there’s not the time or budget to keep it alive when the event’s over. So maybe you choose a date after the event and plan to take the site down then. Or maybe you think your frivolous site will have outlived its life after a year, so perhaps you should plan its death in advance.

The main thing is for everyone to acknowledge what it is you’re making. Is this a site that should last ten years? Or three months? These could be very different things, and cost different amounts of time and money.

If you have a clear “time of death” then perhaps you should set expectations by making this clear on your site. State somewhere that the site will only exist until a certain date. Set in place a clear warning that will appear at a set time before the site’s disappearance. If it’s a site that has user accounts, prepare to contact them well in advance and give them a way to export or transfer their data, if applicable.

3. Do I have the time to keep this site updated?

Unless you’ve decided your site has a short lifespan, and you’re going to wipe it off the web very soon, are you prepared to keep it updated? How much work will that be over 10, 20, 50 years? What is a website like in 2066? Is there a web in 2066?

Over time some or all of these will need tending, fixing, upgrading and improving:

  • Server OS and packages
  • Deployment scripts and tools
  • Database
  • Your back-end code’s language
  • Third-party modules your back-end code uses
  • The site’s framework (Rails, Django, etc) or other fundamental tool (WordPress)
  • Your own back-end code (security fixes, changes required by site growth, etc)
  • Integrations with third-party APIs that will change over time
  • HTML and CSS (for new formats, devices, standards, etc)
  • Your JavaScript (security fixes, device changes, etc)
  • Third-party JavaScript you’ve used.
  • Graphics (new devices, resolutions, etc)

And all of that is assuming an unchanging site, with no new features other than keeping up with the ever-changing tech landscape.

How much time will that take each year? Not a vast amount, but it will take time. The work will seem less and less important over time and become more of a drag when your site is old and little-trafficked.

If your site has users with accounts, who will handle customer support? There will be people who need help with something, people who want to delete things, people who cause trouble, people who break things, people who find bugs, people who want to close their account…

Over the long term there are likely to be occasions when you need to move your site from one server(s) to another. How easy will that be?

Who pays the bills? What happens when the credit card expires? Or the person who put it on their card leaves the company? Which email addresses are the domain, hosting, and accounts on third-party services registered to?

4. What does “closing the site” mean?

If you’ve decided the site has a finite lifespan, what actually happens then? Do you delete the code, shut down the server, and let the domain name lapse? Or does the site have a state between “life” and “non-existent”?

Maybe your site will have an “archived” state. If so, it’s better to plan for it before starting work. Does your code need to work differently for a future archived state? How easy is it to switch to the archived state? Can you turn the site into flat HTML files which will be less work to maintain? Do you have the time and budget to keep even an archived version live for… again, how long?

A couple of examples of putting a closed site into archive mode, even if these weren’t planned from the start (as far as I know):


I don’t think many of us want to ask these questions. I’ve certainly never asked these questions of my own sites.

My knee-jerk reaction is that I want all websites to live “forever”, whatever that means in practicality. But I know that for my personal sites this is increasingly unrealistic. Each one is a little more overhead and, unfortunately, I’m more and more reluctant to start yet another site unless, like a Tumblr, I view it as semi-disposable. If I’d planned sites to be more finite maybe I’d have made more?

I suspect there’s a subset of websites that we can acknowledge in advance aren’t going to last forever, for varying reasons. In those cases we can make this decision clearer from the start, and plan ahead for closure or archiving. If we exceed our expectations — the site’s more popular than expected, we enjoy working on it more than expected, more money comes in — then maybe we can change our plans. But changing plans seems better than having no plans.

And whether we decide the site should live forever or for six months, realising the work that’s involved, even to keep the thing ticking over, is worth doing at the start.

Commenting is disabled on posts once they’re 30 days old.

10 Feb 2016 at Twitter

  • 6:53pm: Reliving the good-old days of setting up my vim configuration by making Atom work just like my vim configuration.
  • 3:38pm: @gwire Yeah… although part of me hopes one of @yoz’s feeds will spring back to life one day, so they might as well stick around.
  • 3:35pm: @gwire Every time I display “all” in my reader I’m surprised at all that old stuff.
  • 3:30pm: @jaggeree A pleasure! Out of my head into yours :)
  • 3:17pm: If I ever rewrite my site I’d like to add an extra field for blog posts, `rss_bonus_content`, that would only appear in the RSS version.
  • 3:11pm: File that one in the “do as I say, not as I do” folder.
  • 3:09pm: I wrote about deciding and planning for a website’s death, or immortality, before starting work on it:…
  • 11:55am: @bensummers [The sound of several things whizzing over my head] But thanks :) Starting to think I should pay more for one server per site…
  • 11:42am: @adamamyl I haven’t noticed them, but I’ll have another look, ta.
  • 11:32am: Maybe I’m making life hard for myself but given the power of cheap servers and requirements of small sites, it doesn’t seem unreasonable.
  • 11:31am: If anyone’s used Ansible to deploy multiple sites to one server (rather than one site to multiple servers) I’d love to see how you did it.
  • 10:44am: @alicebartlett @denisewilton Great minds, etc. I should scroll to the top before replying.
  • 10:43am: @denisewilton Are you loving it?
  • 8:16am: Trying to think of a good metaphor for two people using Twitter to argue about whether short, pithy sayings disguise more subtle issues.

10 Feb 2016 in Links