{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"turning-things-off","title":"Removing a feature, and retiring a site","url":"https://addaly.com/learn/cloud-and-shipping/turning-things-off","position":72,"of":74,"minutes":8,"answer":"Removal is a shipping skill with a sequence: count real usage, announce with a date, offer an export, dark-launch the switch-off, remove code before data.","keyIdea":"Removal is a shipping skill with a sequence: count real usage, announce with a date, offer an export, dark-launch the switch-off, remove code before data, and answer old URLs with a 301 or an honest 410 rather than a redirect to the homepage."},"body":{"format":"markdown","text":"## Deleting is a shipping skill\n\nEverything 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.\n\nMost 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.\n\n## Find out who actually uses it\n\nBefore any argument about whether to remove something, count. Add one log line or one counter to the feature and leave it for a month.\n\nThe 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.\n\n## The removal sequence\n\n1. **Announce**, with a date. Where the users are: in the interface, not only in an email nobody reads.\n2. **Give an export**, if the feature holds anybody's data. This is the part that makes removal legitimate rather than merely convenient.\n3. **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.\n4. **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.\n5. **Remove the code and the routes**, but leave the data.\n6. **Delete the data** after your retention period, not on the same day.\n\nThat gap between step 5 and step 6 is where recoverable mistakes live. Code you can restore from git; data you cannot.\n\n## Keep the URLs alive\n\nWhen 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.\n\nWhat 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.\n\n## Retiring the whole thing\n\nProjects end. Doing it well takes about a day and preserves both your users' work and your own reputation.\n\n- **Say it early**, with a real date, and say why in one honest paragraph.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Say what happened\n\nA 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."},"check":{"question":"A team removes a section of their site and redirects every old URL to the homepage, reasoning that visitors will find what they need. What is the concrete downside?","options":[{"text":"Search engines treat mass redirects to an unrelated page much like a not-found, so the pages leave the index anyway while visitors lose the context they clicked for","correct":true},{"text":"301 redirects pass no signal at all, so the pages should have returned 404","correct":false,"tempting":"Redirects do pass signals when the target is genuinely equivalent; the flaw is the mismatch between old and new content, not the mechanism."},{"text":"Browsers cache 301s permanently, so users can never reach the homepage again","correct":false,"tempting":"Permanent redirects are cached aggressively, which is a reason for care, but it does not block access to the destination."},{"text":"The redirects will overload the server, since every old URL now hits one page","correct":false,"tempting":"Traffic from removed pages is small and the homepage is usually the most cacheable page on the site."}]},"prev":{"slug":"the-maintenance-calendar","title":"The hour a week that keeps it alive","url":"https://addaly.com/learn/cloud-and-shipping/the-maintenance-calendar"},"next":{"slug":"the-paperwork-of-a-public-site","title":"The pages every public site needs","url":"https://addaly.com/learn/cloud-and-shipping/the-paperwork-of-a-public-site"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Removing a feature, and retiring a site', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/turning-things-off (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Removing a feature, and retiring a site","courseTitle":"Shipping It","module":{"index":8,"slug":"running-it-for-years","title":"Running it for years"},"answer":null,"keyIdea":"Removal is a shipping skill with a sequence: count real usage, announce with a date, offer an export, dark-launch the switch-off, remove code before data, and answer old URLs with a 301 or an honest 410 rather than a redirect to the homepage.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"deleting-is-a-shipping-skill","runs":[{"text":"Deleting is a shipping skill"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"find-out-who-actually-uses-it","runs":[{"text":"Find out who actually uses it"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-removal-sequence","runs":[{"text":"The removal sequence"}]},{"t":"ol","start":1,"items":[[{"text":"Announce","b":true},{"text":", with a date. Where the users are: in the interface, not only in an email nobody reads."}],[{"text":"Give an export","b":true},{"text":", if the feature holds anybody’s data. This is the part that makes removal legitimate rather than merely convenient."}],[{"text":"Stop new use.","b":true},{"text":" Hide the entry point, keep it working for existing users. Numbers fall immediately and you learn who the real users are, because they complain."}],[{"text":"Dark-launch the removal.","b":true},{"text":" 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."}],[{"text":"Remove the code and the routes","b":true},{"text":", but leave the data."}],[{"text":"Delete the data","b":true},{"text":" after your retention period, not on the same day."}]]},{"t":"p","runs":[{"text":"That gap between step 5 and step 6 is where recoverable mistakes live. Code you can restore from git; data you cannot."}]},{"t":"h2","id":"keep-the-urls-alive","runs":[{"text":"Keep the URLs alive"}]},{"t":"p","runs":[{"text":"When a page goes away, the links to it do not. A removed page should return a "},{"text":"301","b":true},{"text":" to its nearest replacement where one exists, or a "},{"text":"410 Gone","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"retiring-the-whole-thing","runs":[{"text":"Retiring the whole thing"}]},{"t":"p","runs":[{"text":"Projects end. Doing it well takes about a day and preserves both your users’ work and your own reputation."}]},{"t":"ul","items":[[{"text":"Say it early","b":true},{"text":", with a real date, and say why in one honest paragraph."}],[{"text":"Give everybody a full export","b":true},{"text":" in a format that opens elsewhere: JSON, CSV, Markdown, standard files. Not a proprietary archive that only your dead product can read."}],[{"text":"Keep the domain","b":true},{"text":" 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."}],[{"text":"Consider a static archive.","b":true},{"text":" Most database-backed sites can be crawled into flat HTML with "},{"text":"wget --mirror","code":true},{"text":" 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."}],[{"text":"Turn off the money.","b":true},{"text":" Cancel the subscriptions, remove the card, revoke the keys, and delete the cloud resources, in that order, after the archive is confirmed working."}],[{"text":"Delete the personal data","b":true},{"text":" you no longer have a reason to hold, per the retention lesson. A dead product still has data obligations until the data is gone."}]]},{"t":"h2","id":"say-what-happened","runs":[{"text":"Say what happened"}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A team removes a section of their site and redirects every old URL to the homepage, reasoning that visitors will find what they need. What is the concrete downside?"}],"options":[{"text":[{"text":"Search engines treat mass redirects to an unrelated page much like a not-found, so the pages leave the index anyway while visitors lose the context they clicked for"}],"correct":true,"tempting":null},{"text":[{"text":"301 redirects pass no signal at all, so the pages should have returned 404"}],"correct":false,"tempting":[{"text":"Redirects do pass signals when the target is genuinely equivalent; the flaw is the mismatch between old and new content, not the mechanism."}]},{"text":[{"text":"Browsers cache 301s permanently, so users can never reach the homepage again"}],"correct":false,"tempting":[{"text":"Permanent redirects are cached aggressively, which is a reason for care, but it does not block access to the destination."}]},{"text":[{"text":"The redirects will overload the server, since every old URL now hits one page"}],"correct":false,"tempting":[{"text":"Traffic from removed pages is small and the homepage is usually the most cacheable page on the site."}]}],"order":[3,1,2,0],"why":null},"prev":{"slug":"the-maintenance-calendar","title":"The hour a week that keeps it alive","minutes":8},"next":{"slug":"the-paperwork-of-a-public-site","title":"The pages every public site needs","minutes":9}}}