How to sunset an app gracefully: a checklist

Last updated: July 24, 2026

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Sunsetting an app well means treating the shutdown like a launch in reverse: pick a date, tell people early, protect their data and their money, then close out the infrastructure and paperwork behind it. Do that in order and you keep the goodwill, the reviews, and the option to sell or hand the product off later. Skip it and a quiet shutdown turns into refund disputes and a domain still charging your card two years after you stopped looking at it.

SoleOS published this guide — we build portfolio software for solo founders running more than one product, and "what do I do with the one that's dying" comes up constantly. If you only have one app and a handful of users, you don't need software for this — you need twenty minutes and the checklist below.

The checklist

Work top to bottom. The order matters more than it looks — telling users after you've already turned off billing means refund requests you can't easily fulfill, and revoking API access before you've told anyone means support tickets from people who think they got hacked.

Decide the date and the reason first

Pick an actual date, not "soon." A specific date is what lets you sequence everything else — the user email, the last day of new signups, the final billing cycle — and it forces this to be a decision instead of a slow fade where the app just stops getting updates.

Write down why you're sunsetting it, even if it's just for yourself: no time, no revenue, wrong market, folded into another product. That reason becomes the one honest sentence in your user email — "I can't justify the maintenance time on the revenue this generates" lands better than a vague "refocusing our roadmap." If you're still deciding whether this app is actually done or just neglected, a framework for when to kill a side project is worth reading before you commit to the date.

Tell users early, then stop new ones

Email every active user as soon as the date is set — not the week before. Give them the date, the reason in one line, and what happens to their data and their billing. Then immediately turn off new signups and any free trial that's still live; letting someone start a trial for a product shutting down in three weeks just generates refund requests you didn't need.

Update any public directory listing, community post, or integration marketplace entry too — a stale "actively maintained" badge on a tool you killed months ago is a worse look than finding nothing at all.

Data: exports first, deletion on request

Before the cutoff, give users a straightforward way to get their data out — a CSV export, a JSON dump, whatever format the data is actually in. It doesn't need to be elegant; it needs to exist and be findable from the shutdown email. If you don't already have export functionality built, a static one-time export you send on request is enough — you don't need to ship a self-serve feature for a product you're closing.

Separately, honor deletion requests as they come in rather than waiting for a bulk purge at the end. Keep a log of who asked and when — that log is part of what you'll want in your records later.

Billing: no surprise charges, ever

This is the step most likely to turn into a dispute if you get it wrong. Cancel every active subscription so no future charge goes out — don't just stop responding to support and let Stripe or the App Store keep billing on autopilot. For monthly plans, letting the current period run out is generally fine as long as it's disclosed. For anyone on an annual plan, decide up front whether you're prorating a refund for the unused months, and put that policy in the shutdown email rather than making people ask.

Before you commit to a refund policy, pull the count of active annual subscribers and the average months remaining on their plans — that number tells you whether prorated refunds are a rounding error or a real cost, and it's worth knowing before you promise anything.

Wind down the infrastructure

Once billing and data are handled, kill the technical footprint in order: scheduled jobs and crons first (nothing should be running against a service you're about to shut off), then API keys and webhooks — both the ones you hold for third parties and any you issued to users, since a live key to a dead app is a liability nobody's watching. Then cancel or downgrade the paid services underneath it: hosting, database, transactional email, analytics, any per-seat tool billing you monthly.

Don't just let the domain 404. A short-lived redirect, or a plain page explaining the app is gone and by when data will be deleted, costs nothing and saves users from wondering if they've landed on a phishing page. If you're running several products at once and losing track of which ones need this treatment, a system for managing multiple side projects is the piece to fix before your next shutdown, not during it.

App stores, records, and the paperwork

If it's a mobile or desktop app, remove or unpublish the store listing rather than leaving it live to collect downloads for something that no longer works — a listing still taking payment for a dead app is the fastest way into an App Store or Play Console dispute. Unpublishing rather than deleting outright usually preserves your developer account history if you ever want the app ID back.

Keep financial and legal records — invoices, refund logs, the deletion-request log, final tax filings on the product's revenue — for whatever retention period your accountant or jurisdiction recommends; this varies enough by country and entity structure that it's worth a real answer from whoever does your books, not a guess.

Options short of full shutdown

"Sunset" doesn't have to mean "delete the repo." If the app has a handful of engaged users and no revenue case for you, open-sourcing it lets them keep using and maintaining it without you carrying the cost. If it has real revenue but not enough of your attention, selling it — even for a small amount — often beats running it badly or killing it outright, since a shut-down app is worth nothing to anyone. And if a co-founder, employee, or trusted user wants to keep it alive, handing off the codebase and infrastructure access costs you an afternoon and can save the product entirely. Decide which of these fits before you email users, since the message is different for each.

The earlier you catch a product drifting toward this decision, the more options you keep — a good early sign is something still live, occasionally used, and untouched by you in months. See what actually makes an app a zombie for that definition, and the SoleOS guides library for the rest of the lifecycle checklists.

Frequently asked questions

How much notice should I give users before shutting down?

There's no universal right number — it depends on how embedded the app is in someone's workflow and how much data they'd need to move. What matters more than the exact number of weeks is giving a specific date the first time you say anything, so users can plan instead of wondering if "coming soon" means next month or next year.

Do I have to refund annual subscribers?

Not everywhere, and not automatically — but disclosing your policy (prorated refund, credit, or none) up front in the shutdown email avoids the support burden of people asking individually. If you're unsure what's fair, prorating for the unused months is the version least likely to generate a dispute or a chargeback.

Should I delete user data immediately or wait?

Wait until after the export window closes, and honor individual deletion requests as they come in during that window. Deleting everything the moment you announce the shutdown removes the option for users to get their data out.

Is it better to sunset an app or try to sell it first?

Try to sell or hand it off first if it has any active users or revenue at all — a dead app is worth zero to a buyer, but a small, working one with even modest numbers can find a buyer who wants exactly the size you're tired of running. Reserve a full shutdown for apps where the honest answer is that nobody, including you, wants to keep it running.