Removing a feature, and retiring a site

Deleting is a shipping skill

Everything you keep has a cost: code to maintain, a database table to migrate, a page to test, a dependency to upgrade, a surface to secure. Features that nobody uses charge you rent forever, and the only way to stop paying is to remove them.

Most people find this harder than building. The reason is usually a fear of the small number of users who will notice, which is a real consideration, and it is best handled with a process rather than with avoidance.

Find out who actually uses it

Before any argument about whether to remove something, count. Add one log line or one counter to the feature and leave it for a month.

The result is often decisive: a feature you assumed had a small loyal following has eleven users, four of whom are your own test accounts. Occasionally it goes the other way and the thing you thought was dead is quietly load-bearing for a group nobody spoke to. Either way you are now arguing about a number.

The removal sequence

1. Announce, with a date. Where the users are: in the interface, not only in an email nobody reads.
2. Give an export, if the feature holds anybody’s data. This is the part that makes removal legitimate rather than merely convenient.
3. Stop new use. Hide the entry point, keep it working for existing users. Numbers fall immediately and you learn who the real users are, because they complain.
4. Dark-launch the removal. Turn it off behind a flag for an hour, then a day, and watch what breaks. This is exactly the technique from the kill-switch lesson, used deliberately.
5. Remove the code and the routes, but leave the data.
6. Delete the data after your retention period, not on the same day.

That gap between step 5 and step 6 is where recoverable mistakes live. Code you can restore from git; data you cannot.

Keep the URLs alive

When a page goes away, the links to it do not. A removed page should return a 301 to its nearest replacement where one exists, or a 410 Gone where it does not: 410 tells search engines and other machines that this is deliberate and permanent, which is more honest than a 404 and gets the page removed from indexes faster.

What should not happen is a redirect from every removed page to the homepage. It looks tidy and it is a small lie: the person clicked a specific link and got a shrug. A short page saying what was there, when it went, and where the nearest equivalent is costs an hour and is remembered kindly.

Retiring the whole thing

Projects end. Doing it well takes about a day and preserves both your users’ work and your own reputation.

• Say it early, with a real date, and say why in one honest paragraph.
• Give everybody a full export in a format that opens elsewhere: JSON, CSV, Markdown, standard files. Not a proprietary archive that only your dead product can read.
• Keep the domain for as long as you can afford. Expired domains are bought and repointed, and a site that was yours becomes somebody else’s advertising with your reputation attached to it.
• Consider a static archive. Most database-backed sites can be crawled into flat HTML with wget --mirror or a static-site crawler and hosted for nothing on any static host. The content stays readable, the links keep working, and the running cost goes to zero. This is by far the best outcome for anything with public writing in it.
• Turn off the money. Cancel the subscriptions, remove the card, revoke the keys, and delete the cloud resources, in that order, after the archive is confirmed working.
• Delete the personal data you no longer have a reason to hold, per the retention lesson. A dead product still has data obligations until the data is gone.

Say what happened

A final post explaining what the project was, what it did, what it cost, and why it stopped is worth writing. It closes the thing for the people who used it, and it is the most useful document you will ever produce for the next person considering the same idea, including, quite often, yourself.