How to shut down a product

Recently I shut down one of my projects ListList, and I decided to write a short guide on how to do it properly. There isn’t much practical info about this topic online, so maybe this will help someone.

This guide is about closing a web product, but with some small adjustments it could apply to other kinds of products too.

I won’t go into whether shutting down is the right decision, or what you can do to avoid it. I also won’t cover legal, financial, or technical issues you might need to deal with (especially if you’re closing something big).

Instead, I’ll focus on communicating with your customers to make the shutdown less painful. They rely on your product, and they will be upset when it’s gone. Your job is to make that process as comfortable as possible.

Announcement

You’ve made the tough decision to shut down your product. Now it’s time to inform your customers.

Depending on your product and audience, you should give anywhere from a few weeks to a few years of notice. A general rule: don’t rush people with migration. For example, if your customers are small businesses relying on your API, and shutting down means rewriting code, you should probably give them at least six months so they can pick a new provider and update their systems without stress.

The announcement should be published on your website (where everyone can see it) and also sent through your usual communication channels (email newsletter, social media, etc.).

In the goodbye letter, thank your customers for supporting you and your product all these years. Apologize for the inconvenience the shutdown will cause.

And answer the obvious questions right away:

  1. When will the product be shut down?
  2. Why are you closing it?
  3. Which other products can they use instead?
  4. What happens to their data after the shutdown?
  5. How can they contact you with further questions?

Let’s go into some of these in more detail.

2. Why are you closing it?

Be honest. If there’s no money left to support it — say that. If you’re burned out or tired of working on it — say that. If the project got no traction and you don’t see the point in maintaining it — say that.

It’s not easy, but users appreciate honesty.

Whatever the reason, it’s your decision. Don’t make users feel responsible for it.

Also, tell people what you or your company are doing next (even if it’s just taking a break). It makes the announcement feel more personal.

Since your customers already trust you, don’t just end the relationship there. Point them to your blog, Twitter, or newsletter, and invite them to subscribe so they can follow your future projects (even if you don’t have any yet).

3. Which other products can they use instead?

Do the research for them: list similar services they could migrate to and give a short description of each. If there are good comparison articles, link them.

If these services aren’t free, ask their owners if they’d be willing to offer your users a discount.

If migration is possible, make it easy:

  • Offer exports in a format that works for import.
  • If the other service has an API and you have time, maybe even build automated migration.

Rule of thumb: for the customer, migration should be as quick and painless as possible.

Also, consider open-sourcing your product so customers can run it locally. If you do, make sure there’s a way for them to migrate their data from your instance to theirs.

4. What happens to their data after the shutdown?

If you store user data, make it clear what happens after shutdown. Will you delete it? If yes, explain that exports will only be available for a limited time before it’s gone.

If you don’t plan to delete it, explain why and how it will be used. In that case, still let users request deletion — you’re legally obliged to (GDPR and all).

Think about how people may want to use their data later:

  • Some will want programmatic access (JSON, CSV).
  • Others may just want something readable (HTML, plain text).

Offer both machine-readable and human-readable export options if you can.

After the announcement

Once you’ve announced the closure, questions will start coming in. Answer them promptly to avoid frustrating people further.

Close registration

Consider closing sign-ups for new users. If you keep registration open, at least put a clear notice that the service will be shutting down soon. Otherwise, new users will sign up only to find out later that it’s ending.

Give a discount

If your service is paid, consider giving a discount or even making it free for the remaining time. People will appreciate the gesture.

Update the help section

Update your help pages with info about the shutdown: how to migrate, what happens to data, and other common questions.

Your main announcement doesn’t need to include all the details — just link to these updated help articles.

Remind users

Some people will miss or forget the first announcement. Send a reminder about 1–2 weeks before the shutdown.

After the shutdown

The day has come. You’ve shut down the product and made the final announcement.

If possible, keep your website online even after the shutdown. There will always be people who missed the news or stumbled across your product later. Don’t leave them staring at a blank page wondering what happened.

You probably won’t want to keep all communication channels active. Make it clear which ones you’re closing (e.g., Facebook, Twitter), but keep at least one way for people to reach you. There will always be late questions.