How to shut down a SaaS product: close it well, keep the people

Most advice on shutting a product down is written for a product manager retiring a feature inside a company. Founders have a different problem. You are not managing stakeholders. You are telling a few hundred people, one of whom is probably paying you this month, that the thing they rely on is going away. And the people watching how you handle it are the same people who will decide whether to try whatever you build next.

That is why a shutdown is a marketing act. Done badly it is a screenshot on a discussion site. Done well it is the most honest thing you will ever publish, and it builds the one asset a failed product can still leave you: trust.

Is it really over? The signals that count

Shut down when the evidence says the product is finished, not when a hard week says so. A bad month is data. A pattern you tried to break and could not is a decision. Here is how to tell them apart.

If your project went quiet rather than failed, you may not be shutting anything down at all. Our guide to restarting a stalled project walks through the four causes of a stall and the one question that separates a restart from a close. If the answer is close, come back here.

One more option before you decide: a pivot. If the code works and the audience is wrong, read how to announce a pivot first. A pivot keeps the users. A shutdown does not.

Who do you owe what when you shut down?

You owe different things to different people, and the order matters because the paying users get the most.

• Paying users: notice, a working export, a refund for any prepaid time beyond the end date, and a real person to write to.
• Free users: notice and an export. They paid you in attention, and a short email is the minimum.
• People who built on your API or integrations: the longest notice of anyone, because their product breaks when yours does.
• Anyone who linked to you or reviewed you: nothing formal, but a redirect and an honest closing note are good manners that also protect your reputation.

Read your own terms of service before you write anything. Your commitments there decide your refund obligations, and nobody should find out in a dispute that you promised something you forgot about. This guide is practical advice, not legal advice. If you have significant contracts, spend an hour with a lawyer.

What does a fair shutdown timeline look like?

A fair shutdown runs on a published timeline with a user-facing promise at every step. Ninety days of notice is a good default for anything people pay for. Matt Swanson, who shut down his own SaaS product, gave three months and waived the cost of paid plans during that period, and wrote up the principles he used in Closing Down a Product, Gracefully. A free side project with a few users can close faster. Here is the sequence, with what you owe at each stage.

Two rules hold the whole timeline together. First, never move the date earlier once you announce it. Moving it later is fine and usually welcome. Second, keep the product working for the whole period. Quietly letting it decay while you wind down is the fastest way to turn a sad email into an angry one.

What are the data export and refund non-negotiables?

Build the export before you announce, not after. A promise to provide one later reads as a dodge. A button that works the day you send the email reads as respect. Use a format people can actually open, such as CSV or JSON, and include everything a user created, not only what was convenient to dump. Pointing people to your API and wishing them luck does not count.

Export is also a legal matter in some places. In the EU, GDPR gives people a right to receive the personal data they provided in a structured, commonly used, machine-readable format. The text of GDPR Article 20 on data portability is short and worth reading if you have European users.

For refunds, keep it simple and fair:

1. Stop recurring charges on announcement day. Do not bill someone for a product you have told them is ending.
2. Refund prepaid time past the end date. Annual plans get the unused months back. Do the math for each customer and send it without being asked.
3. Say it in the announcement. People should not have to email to learn they are getting money back.

What should the shutdown post say?

The post should answer five questions in the first screen: what is happening, when, why, what happens to my data, and what do I do now. Everything else is optional. Write it in plain words and publish it in two places: emailed to every user, and live on your site where anyone can find it.

Naming alternatives feels strange, because you are sending your users to competitors. Do it anyway. You know the landscape better than they do, and the generosity is what people remember. If you want a model for the tone, our guide to launching a second product covers how the trust you keep from the first one carries into the next.

What do you keep when a product closes?

Most founders walk away from everything: the domain lapses, the listings go stale, the list is forgotten. That is the expensive mistake. A product that ran for a year or more left behind assets that took real effort to earn, and almost all of them can outlive the product.

The listings and backlinks are the part people miss. If you followed our startup launch directories guide, you have profiles on a dozen sites that still send people to you. Update each one with a closing note and a link to what you do next. For the code, GitHub lets you archive a repository, which keeps it readable and clearly marked as no longer maintained.

Last, keep a record where people can find it. A founder who has shipped, learned and closed something cleanly has a track record, and a profile that shows it is worth more than an empty one. Put the closed product on your founder profile with a line on what it taught you, and the next launch starts with people who already trust you. The wider plan for turning a portfolio of small bets into an audience sits in our go-to-market guide for solo founders.

Frequently asked questions