Products & Launches · 3 min read
When a Side Project Ends: How to Sunset a Product Gracefully
Short answer
To sunset a product gracefully, decide clearly, give users plenty of notice with a firm date, let them export their data in a common format, stop charging and refund fairly, point them to alternatives, keep important links working, and thank them.
Key takeaways
- Give generous notice, often 30 to 90 days, with one clear shutdown date.
- Data export in a common format (CSV, JSON) is the most important courtesy.
- Stop new charges immediately and handle refunds plainly.
- Keep the domain and key pages up with a clear notice, or redirect them somewhere useful.
Most products end eventually. Side projects especially: the people who built them move on, costs outgrow revenue, or the problem they solved goes away. How a product ends shapes how people remember the team behind it.
How do you decide it's time?
Write down the reasons, the alternatives you considered and the cost of keeping it running, then set a date.
Common reasons: the product isn't sustainable, the team's time is needed elsewhere, a platform change broke the core feature, or better alternatives now exist. Honest reasons make the announcement easier to write and easier for users to accept.
What's the shutdown timeline?
Announce, freeze, export, shut down, with dates for each.
| Step | When | What happens |
|---|---|---|
| Decide and plan | Before announcing | Date, refund policy, export, alternatives |
| Announce | Day 0 | Email, in-app notice, post on X and the blog |
| Stop sign-ups and new charges | Day 0 | No new customers, no renewals |
| Export available | Day 0 to shutdown | Data downloadable in CSV or JSON |
| Reminders | Halfway, one week before, day before | Short, with the export link |
| Shut down | Final date | Service off, notice page up |
| Data deletion | Stated date after shutdown | As promised in the announcement |
What should the announcement say?
What's happening, when, why in a sentence or two, what users should do, and thanks.
Put the date and the action ("export your data by June 30") in the first lines. Explain the reason briefly without self-pity. List alternatives honestly, including competitors. Say what happens to user data and when it will be deleted. Thank people. If you announce on X, draft the announcement and the reminders together in the Share Queue with their dates, so none of them are forgotten.
What do users need most?
Their data, in a format they can use elsewhere.
A CSV or JSON export, documented in a sentence or two, is the single most valuable thing you can offer. Test it with real accounts before announcing. If your product held something like saved searches or lists, export them in a form another tool could import.
What about payments?
Stop renewals immediately, and refund unused time on a clear, simple rule.
Users remember billing surprises more than anything else. Announce the refund rule in the first message, process it without making people ask, and confirm when it's done.
What happens to the website and links?
Keep key pages up with a shutdown notice for as long as you can, or redirect them somewhere useful.
Links to your product live on in blog posts, forums and bookmarks for years. A short page explaining that the product has closed, with the date and a thank-you, is better than an error. If the domain will eventually lapse, know that someone else may register it and build something unrelated at the same address. That's one more reason to make your goodbye clear while you still control it.
How do you close well for the team?
Write down what you learned, while it's fresh.
A short internal note on what worked, what didn't and what you'd do differently is worth more than any launch retrospective. The habits you built for this product, from writing updates to talking with users, carry into the next one.
Questions
How much notice should users get?
It depends on how much they rely on the product. Thirty days is a minimum for most tools; products that hold important data or are built into workflows deserve 60 to 90 days or more.
Should I open-source a product I'm shutting down?
Sometimes. It can let users self-host. Only do it if the code is clean of secrets and you're comfortable with others maintaining forks.
What should happen to the domain?
If you can, keep it with a page explaining the shutdown for a while. If you let it lapse, someone else may register it and use your old links' reputation for something unrelated.