Closing well is a skill too: a shutdown and farewell playbook for vibe projects

Every vibe project ends in one of two ways: somebody takes it over, or it closes. Takeovers have endless tutorials; closing has almost none. The result is that many projects do not "close" — they rot: a domain expires one day, a server bill goes unpaid another day, users discover one day that they cannot log in, and the author leaves a social post saying "been busy lately", and then nothing. Closing well is not a loser's dignity; it is a craft that can be done from a checklist.

This guide follows one fictional example throughout: Shen Qing (a fictional person) built a to-do list tool called "Lime List" (a fictional product) over three years, with more than 800 paying users, and one day decides to shut it down in 90 days because maintenance costs exceed revenue. All names, product names, and numbers are fictional examples, used only to explain the method, and do not refer to any real project. If you are considering closing your own project, swap "Lime List" for your product and the day counts for your reality; the checklist itself needs no change.

Answer three questions before announcing anything

Before announcing, write three questions down on paper. First, why are you closing, in one sentence: is nobody using it, are costs unsustainable, or do you personally have no time left? Different reasons need different farewell letters. "Nobody uses it" can be stated frankly with numbers, "costs are unsustainable" can show the maths openly, and "no time" should not be dressed up as a market reason. Second, is there another way out: open-sourcing, handing it to the community, selling it to a peer, or downgrading it to a free static version? If any of these four works, closing is not the only option. Third, what is the users' core data: for a list tool it is task data, for a ledger tool it is the books, for a writing tool it is the articles. Circle "the thing users can least afford to lose" first; the whole shutdown plan must revolve around it.

Shen Qing's (fictional) answers look like this: the reason is that server and SMS costs exceed subscription revenue, and she will be caring for family full-time for the next year and cannot respond to outages; she tried the alternatives — open-sourcing found no maintainer, handover talks with two parties went nowhere, it could not be sold, and a static downgrade would lose syncing and amount to a different product — so she decided to shut it down completely; and what users can least afford to lose is their task data and attachments. Once those three answers are written down, closing stops being an emotional decision and becomes a work plan. Many shutdowns rot precisely because this step is skipped: the author announces at their lowest emotional point, and only afterwards discovers they never knew what users cared about most.

A countdown timeline: how to split 90 days

The timeline must be planned backwards, not forwards. If shutdown day is day T — the day the servers stop — then T-90 is announcement day, T-60 is the day the export tool goes live, T-30 is the last billing day, T-14 is the reminder peak, T-7 is the read-only switch day, T is the stop day, and T+30 is the data-deletion day. Every milestone needs a clear "what users can do" and "what the author must do", not just a date.

Announcement day must ship three things at once: the farewell letter, the export tool, and the timeline. Sending only the farewell letter without an export tool tells users "your stuff is going away, but you cannot take it yet", which doubles panic and complaints. The export tool can go live a few days after the announcement, but not more than two weeks later; beyond that, users will assume you were never ready. The last billing day must fall at least a month before shutdown: still charging right before shutdown is the fastest way to turn a sad ending into refund disputes and a reputation collapse. The read-only switch day means turning the product a week early into "view and export only, no new or edited content", so that even someone who only hears the news at the last minute does not write a batch of new data on the final night only to lose it.

The data-deletion day must be written into the timeline separately, and actually carried out. Many projects promise "data deleted 30 days after shutdown", but in practice nobody tends the servers after shutdown and database backups keep sitting on some cloud drive. Deletion day work includes deleting the production database, backups, data in third-party services, and personal-data residue in logs, followed by a public completion note. A shutdown that does not actually delete is worse for trust than no shutdown at all.

Data export: three tiers, not one

The most common export mistake is offering only one format. Technical users want JSON or CSV, ordinary users want something they can open directly, and serious users want a complete archive with attachments. So export must come in three tiers: first, "one-click package download" — one archive containing all data and attachments, which an ordinary user can grab in one click; second, "standard-format export" — CSV or JSON, easy to import into another tool; third, "per-item export" — a single article, list, or month can be taken on its own, for users who only need part of their data.

Two easily missed steps come before exporting. First, an export preview: let users see "how many items, how many attachments, how large" before downloading. Without a preview, users download repeatedly, repeatedly suspecting they missed something. Second, export verification: after downloading, give a simple self-check, such as "your archive should contain three folders and one readme", or a count of items and attachments to compare against. Shen Qing (fictional) added one more thing to "Lime List": a one-page plain-text readme inside the export package explaining what each file means and how to import it into other tools generally. That single page drew the most post-shutdown thanks — because it answered the users' real question: "Now that I have these files, what do I do with them?"

Attachments, images, comments, and collaboration records — the "secondary data" — are the easiest to leave out. A list tool exports task text but not the comments under tasks; a ledger exports entries but not invoice photos; a writing tool exports articles but not discussion in the comments. The export checklist must be ticked item by item against the data model: main data, attachments, comments, tags, collaboration relationships, settings — everything exportable listed, and everything not exportable explained with its reason and alternative. Stating "what cannot be exported" is far more dignified than pretending "everything is exported".

Subscriptions and refunds: stop charging first, then talk compensation

The order of subscription handling cannot be wrong: first, stop all automatic charges; second, handle remaining time; third, talk about compensation. Reverse the order — talk compensation first, stop charging later — and one more billing cycle slips through in between, making even the kindest compensation sound hollow. Remaining time must come with user choice: pro-rata refund, or conversion into an extended export period or credit toward another product. Do not offer only one option, and never default to "no refund, only extension" — extending the life of a product about to shut down is worthless to users.

Refund rules must be written in black and white: which cases get full refunds, which get pro-rata refunds, how many days refunds take, through which channel to apply, and who handles disputes. Shen Qing's (fictional) approach: annual users refunded pro-rata by remaining days, monthly users refunded for unused days after shutdown day, the refund window open until 30 days after shutdown, and the application link placed in three places — the farewell letter, the in-product announcement, and email. The more specific the rules, the lighter the support load; the vaguer the rules, the more users assume the worst and ask in the sharpest tone.

Third-party payment and app-store subscriptions need separate handling. Web subscriptions can be stopped directly in the back office, but Apple and Google in-app subscriptions must be cancelled by users in the store, or handled by the author through store interfaces. The farewell letter must spell out the cancellation path for each channel, with screenshots or steps — not just "please cancel your subscription yourself". Many users do not refuse to cancel; they simply do not know which menu to open.

Communication: four letters, each to its own reader

At least four letters are needed during shutdown, each with a different reader and job. The first is the announcement letter, to all users: one sentence of reason, one timeline, one export link, one paragraph of refund rules — no lyricism, no long essay. The second is the reminder letter, sent at T-14 and T-7, to users who have not exported yet: only "how much of your data is still unexported, what the deadline is, where to click to export" — do not repeat the whole first letter. The third is the thank-you letter, on shutdown day: thanks for using it, the data-deletion date, contact details — do not use this moment to promote a new product. The fourth is the completion letter, after data deletion: confirmation that deletion is done, the archive page address, and future contact details.

All four letters share one tone principle: facts first, feelings second. During shutdown, what users need most is certainty: is my data still there, when will it be gone, where do I get it, what about my money. The first three lines of every letter must answer that letter's certainty questions; feelings and memories can follow, but cannot lead. Shen Qing's (fictional) announcement letter opens with exactly this: "Lime List will stop service in 90 days; your data can be exported in one click before then; annual users will be refunded pro-rata for remaining days." Three sentences, three certainties; only then come reasons and thanks.

Channels must be layered too: in-product announcement, email, and social media — all three, but not simply copied. The in-product announcement serves current users, with operational steps; email serves all registered users, with the timeline and refunds; social media serves onlookers and potential users, with reasons and the archive address. Posting only on social media and not emailing assumes "not seeing it is your own fault"; emailing without an in-product announcement means active users hear it last.

Read-only archive: a dignified headstone for the product

Shutdown does not mean erasure from the internet. Many projects, once closed, leave their original URLs returning 404, so every link in search results, tutorials, and recommendations dies overnight. The better approach is a read-only archive page: the original domain redirects to one page stating what the product was, why it closed, until when exports were available, recommended alternatives (if any), and contact details. The archive page does not need full functionality, but it must preserve the basic fact that "this product once existed".

The archive page must also handle redirects properly: old help-doc links, blog links, and shared links should redirect to the corresponding archive note where possible, not all to the homepage. Shared links matter most: lists, articles, and pages users shared in the past should open to a clear explanation after shutdown, not a blank page or a 404. Writing redirect rules is not hard; the hard part is being willing to spend half a day on them during the final week of shutdown. Whether that half-day is worth it depends on how much you respect the fact that "other people once wrote about your product".

The wind-down checklist: 30 more days of work after shutdown day

Shutdown day is not the finish line; a wind-down checklist follows. First, confirm all refunds have landed and all disputes are closed; second, confirm data deletion followed the timeline, and write the completion note; third, cancel or transfer third-party services no longer needed — SMS, email, payments, analytics, error monitoring — stop what can be stopped, delete what can be deleted, so you are not still paying six months later for a product that no longer exists; fourth, handle the domain and trademark: the domain can keep the archive page, or be released, but that must be planned, not left to expire and be snatched for phishing; fifth, write an internal retrospective: which decisions were right, which were wrong, what you would prepare earlier if you did it again. It need not be public, but it must be written, or the next project will repeat the same shutdown.

Team projects need one more step: handover and thanks. Who owns the 30-day wind-down, who owns support close-out, who owns deletion execution — each with a name and a deadline. Volunteers, part-timers, and community contributors, if any, should also be thanked publicly. The fastest way to chill people during shutdown is "helped all along, never named at the end".

One easily underestimated wind-down task remains: answering "the people who ask later". Three months, six months after shutdown, emails will still arrive asking "can I still get my old data back" or "will you restart". Prepare a standard reply template in advance: data was deleted per the timeline and cannot be recovered, the archive page address, recommended alternatives. The person handling support close-out can reuse it directly instead of composing a fresh reply each time. A template means shutdown has truly ended, instead of lingering forever as a to-do in the author's inbox.

Anti-patterns: the five most common rotten endings

First, sudden death: no notice at all, servers simply switched off. Users' data, subscriptions, and collaboration relationships are left hanging, and reputation drops to zero. Second, endless postponement: shutdown announced, then delayed again and again, so users never know which day is truly the last, and exports and refunds hang in limbo. Third, closing the product but not the billing: service stopped, automatic charges still running — the only shutdown flavour that turns "regret" into "dispute". Fourth, performative export: the export button exists, but the files cannot be opened, or lack attachments and comments — users received something equal to nothing. Fifth, emotional farewell: the announcement letter written as an accusation, blaming users, the market, and competitors, turning a dignified goodbye into a public break-up.

These five rotten endings share one trait: the author treats shutdown as "an ending", while users treat it as "a handover". An ending needs only a decision; a handover needs a checklist. Everything in this article is really just translating "ending" into "handover": timeline, export, refunds, communication, archive, wind-down — each one a link in the handover chain. Do them all, and the project can close while trust stays.

How this differs from neighbouring guides already published

This guide covers shutting down a whole product, with distinct jobs from several neighbours: the feature-sunset guide covers retiring a single feature, not a whole product disappearing; the maintenance-mode and read-only-window guide covers temporary read-only operation with recovery afterwards, while this guide's read-only phase is a transition to permanent archiving; the account-deletion and data-erasure guide covers a single user actively deleting their own account, while this guide covers an author actively shutting down service for everyone; the cancel-flow and save-offers guide covers the moment a user clicks "cancel subscription", while this guide covers the moment an author decides "to stop providing service"; the data-archiving guide covers methods for long-term data preservation, while this guide covers where archiving sits inside the full shutdown flow. When reading, distinguish by "who is deciding, and how wide the decision reaches", and they will not blur together.