The Decision to Sunset a Product

What you actually need to know

• Give 90 days notice minimum. Six months for annual customers. Review contracts before setting the date.
• Refund unused prepaid subscription time. Keeping it is not just ethically wrong, it creates legal liability.
• Provide a complete data export and keep it available through the end of the notice period and beyond.
• Try to sell before shutting down. A product with customers is worth something to someone.
• How you shut down is part of your professional reputation. It follows you to the next thing.

The core argument

A product shutdown is a test of the team's values under pressure. The business case for a fast shutdown is compelling: stop spending money on a product that is not generating return, redeploy the team, move on. The case for a responsible shutdown is less immediately compelling but more important: the customers who trusted the product with their data and their workflows deserve time and support to transition.

The founders who handle product sunsets well understand that how they shut something down is part of their professional reputation. The SaaS market is small enough that how a specific shutdown was handled gets remembered. Founders who moved fast, kept prepaid revenue, and left customers scrambling for data exports find the story told in the communities where they are trying to sell the next product.

The founders who get credit for their shutdowns gave long notice, made data export easy, helped customers find alternatives, and sometimes personally assisted the migration. Some of these founders saw their next product launch welcomed by the same customers who used the product they shut down. Trust is portable.

Exploring alternatives before announcing

Before announcing a shutdown, run a 30-day exploration of alternatives. The alternatives are acquisition and restructuring.

Acquisition. A product with paying customers is worth something. Even at a low multiple of revenue, a sale provides continuity for customers and some return for the seller. Approach two to three potential acquirers who might value the customer base or the technology. The conversation is often shorter than founders expect. A product with $5,000 MRR might sell for $100,000 to $200,000 to a strategic buyer. That is not nothing, and it keeps customers served.

Restructuring. If the product cannot sustain its current cost structure, can it survive at a lower one? Moving to a self-serve model with no support, removing features that require significant infrastructure, and raising prices to reflect the true cost might allow the product to survive with a smaller but sustainable customer base. Not all sunsets are necessary. Some products are kept alive at a lower operating cost by a founder who prefers minimal revenue to zero revenue.

If both alternatives are genuinely not viable, the shutdown proceeds. But the exploration should be documented. Customers who learn that alternatives were explored before the shutdown feel more respected than customers who learn the decision was made in a week.

The shutdown communication sequence

The announcement must be specific and complete. Customers need to know: when the product will stop working, when their access will end, how to export their data, what happens to their remaining subscription payments, and what alternatives the team recommends.

Announce 90 days before shutdown for month-to-month customers. The announcement should include: the specific shutdown date, the data export process, the refund policy, the alternative products the team recommends (identify at least two), and a direct contact for questions.

At 60 days: reminder with data export status. Have any customers not yet exported their data? Send them a direct follow-up.

At 30 days: final reminder with the exact shutdown date and time. Confirm data export availability.

At shutdown: disable new signups. Stop billing. Export data one final time and make it available. Send a final message to all customers confirming the shutdown.

After shutdown: keep the data export available for an additional 90 days. Some customers will not have migrated by the shutdown date. Making data available after shutdown is the minimum standard of responsibility.

Handling the team through a product sunset

Product sunsets are hard on teams as well as customers. The team built the product. They worked through the hard periods. Shutting it down feels like judgment on their work.

The responsible handling includes: being honest about the business reasons rather than framing the shutdown as a technical or product failure, giving the team reasonable notice so they can plan, and helping them find their next roles if the shutdown means layoffs.

Engineers who worked on a product that was sunset professionally, with care for customers and the team, will work with that founder again. Engineers who experienced a chaotic shutdown where customers were left stranded and the team was surprised with short notice will tell that story to every hiring conversation they have.

Common mistakes founders make when sunsetting a product

1. Announcing and shutting down in the same month. Customers need time to evaluate alternatives and migrate. Short notice is disrespectful regardless of the business pressure to move fast.
2. Retaining prepaid revenue for undelivered service. This is both unethical and legally problematic. Refund the unused portion.
3. Deleting customer data before the export period ends. Customers who cannot get their data out will pursue legal remedies. Keep data available through the end of the notice period.
4. Not exploring acquisition before announcing shutdown. A sale is almost always better for customers than a shutdown.
5. Not recommending alternatives. "Find something else" is not a migration path. Identify two to three alternatives, explain how they compare, and make the comparison easy for customers.

Where to start: a 3-step responsible shutdown

Step 1: Run the 30-day alternatives exploration. Approach two to three potential acquirers. Evaluate whether a restructured lower-cost model is viable. Document the findings. If neither alternative works, proceed to announcement.

Step 2: Calculate the refund obligation before announcing. Total prepaid annual subscriptions. Calculate the prorate for unused months. Confirm the refund amount can be paid. The financial obligation must be clear before the public announcement.

Step 3: Draft the announcement before setting the date. The announcement must be complete before it goes out. Shutdown date, data export process, refund policy, alternative recommendations, direct contact for questions. If any of these cannot be included in the announcement, the shutdown is not yet ready to announce.

Responsibility in the Hard Decisions

Yashveer Singh. Founder of Yashveer Labs. The way a company closes a chapter says something about how it opens the next one. The technical and operational responsibility required for a professional shutdown, the data exports, the migration paths, the communication, is engineering work. I build the systems that make these transitions possible. If you are planning a product sunset and need the technical foundation to do it right, that is a specific scope I can help with.

Related reading

• The Decision to Sunset a Feature
• The Decision to Sell the Company
• The Decision to Walk Away
• The Data Export Feature: Why Customers Always Ask and Founders Always Delay