Playbooks / How to shut down a SaaS product cleanly

Playbook

How to shut down a SaaS product cleanly

Shutting a product down is more than turning off the server. Every service it used keeps billing, every key keeps working and every domain keeps renewing, or lapses into someone else's hands. This checklist closes it all out.

Last checked 2026-11-09

Founders who run several products usually sunset one the same way: they stop working on it, and months later find a renewal charge for a database nobody uses. A clean shutdown takes an afternoon and stops that.

Before you start

• Tell your users first. Give paying customers notice, stop new signups, cancel or refund their subscriptions, and give them a way to export their data. Check your own terms for what you promised.
• Decide what you're keeping. The domain, the code, the customer list, the brand. Write it down now, before you start cancelling things.
• Check what's shared. A Stripe account, an email domain or a cloud account might serve another of your products. Anything shared stays running.

The steps

1. Review everything the product uses. List every service, account, subscription, key and domain behind it: hosting, database, payments, email, auth, analytics, monitoring, AI APIs, app stores. Check billing statements and your inbox for anything you forgot.
2. Export the data you want to keep. Download data, backups and records you'll want later, before you cancel anything. That includes invoices and payment records you may need for tax.
3. Cancel subscriptions. Cancel each one so it stops billing, and keep the confirmation. Watch for annual plans: cancelling may only stop the next renewal, so note when each one ends.
4. Revoke keys and tokens. Revoke every API key, token and webhook secret the product used. A key for a dead product is pure risk: nobody watches it, and it still works.
5. Decide each domain. For each domain, choose: keep it renewing, let it lapse, or transfer it to another registrar or owner.
6. Close the accounts. Close provider accounts that only this product used. Skip any account another product still needs.
7. Retire the project. Archive the repo, take down the deployment and mark the product as retired in your own records, so you know it's done.

Domains deserve a real decision

Before letting a domain lapse, check that no account (a provider login, an app store account, your registrar itself) still uses an email address on it. Move those to another address first. If the product had real users or links pointing at it, keeping the domain for a year or two is usually cheap insurance. If you're selling or handing the product to someone, transfer the domain rather than letting it expire.

A shutdown email you can copy

Send it at least 30 days before the last day, or longer if your terms promise it. Edit every bracket.

Subject: [Product] is shutting down on [date]

Hi [name],

We've decided to shut down [Product]. The last day you can use it is [date].

What happens next
- Until [date], [Product] works as normal.
- New signups are closed as of today.

Your data
- You can export everything at [export link or steps] until [date].
- After [date] we'll delete your data within [number] days.

Your payments
- Your subscription won't renew after today.
- [We'll refund the unused part of your current period by [date]. / Annual customers get a refund for the months left.]

Questions? Reply to this email or write to [support email] and we'll help.

Thank you for using [Product].
[Your name]

Keep the domain

Keep the domain for a year or longer after the shutdown, even if the product is gone. If it lapses, someone else can register it and receive email sent to your addresses on it, including password-reset emails for any account that still uses one. Before you let it go, move every login off addresses on that domain, and check your registrar account too. The renewal is cheap next to taking over your old users' accounts.

Things that keep billing

• Annual plans that renew months after you stopped thinking about the product.
• Usage-based services with a minimum monthly fee, or storage that keeps growing.
• Paid add-ons attached to a free plan, like a custom domain or extra seats.
• App store developer memberships and SSL certificates with their own renewal dates.
• Email sending, monitoring and analytics tools set up once and forgotten.

Things that keep working

A shut-down product still has live credentials: API keys in old deployments, tokens in CI, OAuth apps that can still sign users in, webhooks that still accept requests. Revoke them, even if the server is gone. If you're not sure a key is unused, rotate it first using the key rotation playbook, and revoke the replacement when nothing breaks. If you find a key that was committed or shared somewhere public along the way, treat it as a leaked key.

Pausing instead

Not ready to shut it down? You can pause instead: downgrade paid plans, scale hosting to zero, keep domains and certificates alive, and set a date to decide. Just keep the keys rotated and the domain renewing while it sleeps.

Do this in StackHangar

StackHangar runs this playbook for a whole project at once. Because your vault already groups every key, account, subscription and domain by product, step 1 is done before you start, and each later step lists the exact items and the account that owns them.

• Domains get an explicit keep, lapse or transfer choice. Kept domains stay in your vault with renewal alerts.
• Items shared with another project can be marked as still in use, so you don't cancel something a live product needs.
• When you finish, the project's items move to deleted for 30 days and their alerts stop. Free covers 2 projects.