A Support Workflow for Sunsetting an Indie Product

Shutting down a product creates a lot of support work in a short time. Each customer wants answers to the same few questions: When does it stop working? What happens to my data? Will I get a refund? What should I use instead?

The short answer: settle every one of those facts before you announce anything. Then turn them into one public page and a set of saved replies. Announce early on every channel you have. Leave a support channel open after the product goes dark. The rest of this post goes through that workflow one phase at a time, with platform details for Stripe, the App Store, and Google Play.

The workflow at a glance

The 31-day figure comes from Apple's guidance for auto-renewable subscriptions (covered below). It works as a sensible minimum for other products too. The other timings are suggestions, not requirements.

Phase 1: Decide the facts before you write a single reply

Most of the pain in a shutdown comes from answering questions you haven't decided yet. If you make up answers as emails arrive, different customers get different answers, and you end up writing apologies later.

Write a short internal fact sheet that answers these questions:

• Key dates. When do new sign-ups stop? When do renewals stop? When does the service stop working? When will data be deleted?
• What keeps working. Will installed apps keep running offline? Will a self-hosted or local version still work? Will sync, logins, or APIs stop?
• Refund policy. Prorated refunds for unused time, refunds only for recent annual purchases, or service until the end of the paid period? Pick one rule and write it down.
• Data. What customers can export, in which formats, until what date, and when (or whether) you'll delete everything.
• Alternatives. Any competitors or open-source tools you're comfortable suggesting. Also say whether you'll publish the source code.
• Contact after shutdown. Which address stays monitored, and for how long.

If you run more than one product, decide how the shutdown fits into your shared inbox. Handling support across multiple indie products covers setting up separate tags and priorities.

Phase 2: Turn the facts into support assets

Once the fact sheet is done, turn it into material you can reuse:

1. A public shutdown page or FAQ. It's the single source of truth. Every email, in-app message, and store reply links to it.
2. Saved replies for the predictable questions. Usually: dates, refunds, data export, "can I keep using it offline?", alternatives, and "can I buy the product or the code?"
3. Inbox tags or labels, such as sunset-refund, sunset-data, sunset-feedback, and sunset-other. That way you can work through one category at a time.
4. An internal escalation list. Cases you'll handle personally and not with a template: customers who depend on the product for their business, unusual billing situations, and legal or privacy requests.

This is the same idea as building a support buffer before shipping. You do the thinking before the volume arrives, not during it.

Phase 3: Announce and close the door to new customers

Tell people everywhere they might look

One email isn't enough. Some people filter your emails or have changed addresses. Apple's guidance for discontinuing a subscription recommends giving subscribers notice "through channels such as email, website, and in-app messaging" at least 31 days before the service ends (Apple Developer). That's good practice for any product.

A clear announcement covers:

• What is happening, in one sentence
• The key dates from your fact sheet
• What customers need to do (if anything) and by when
• What happens to payments and data
• A link to the full FAQ and a way to contact you

Give the reason briefly and honestly if you want to. Customers mostly need the practical details.

Stop new sign-ups and purchases

Taking new money after you've announced a shutdown creates refund requests and ill will. Close every purchase path:

• Web checkout and sign-up forms: remove them or replace them with a link to the shutdown notice.
• Google Play: unpublishing stops new installs. Google says "existing users can still use your app and receive app updates, but new users won't find and download it on Google Play" (Play Console Help). So you can still ship a final update, such as one with an export button or an in-app notice.
• App Store: App Store Connect has a "Remove from Sale" option for apps. Apple's official help pages don't clearly document what it means for existing users, such as whether they can re-download. Developers are still asking about it on the Apple Developer Forums. Check current Apple documentation, or ask Apple Developer Support, before you promise customers anything about re-downloads.

Phase 4: Handle the wave by category

You'll probably get a burst of messages right after the announcement. Don't answer them in arrival order. Sort them by tag and work through one category at a time:

1. Urgent and high-dependency customers first. These are people whose business relies on the product, or anyone with a deadline that falls before your shutdown date.
2. Billing questions. These need accurate, consistent answers, and errors cost money.
3. Data and export questions. Point to the export instructions and confirm deadlines.
4. Feedback and goodbyes. These matter, but they can wait a day. A short, sincere reply is enough.

Many customers will keep using older builds after updates stop. Supporting customers on older product versions explains how to set expectations for software you no longer maintain.

Hypothetical example replies

These are illustrative templates, not real exchanges. Adjust them to your own fact sheet and voice.

Hypothetical: "Will I get a refund?"

Thanks for asking. Your annual plan renewed in March, so you'll get a prorated refund for the months after the shutdown date. It will go back to your original payment method within the next week. Full details are on our shutdown page: [link].

Hypothetical: "Can I keep using the app offline?"

Yes. The desktop app will keep opening and editing local files after the shutdown date. Sync and sign-in will stop, so please export anything stored only in the cloud before [date]. Here's how: [link].

Hypothetical: "Why are you shutting it down?"

Honestly, it hasn't earned enough to cover hosting and the time it needs, and I'd rather shut it down properly than let it decay. Thank you for using it. I know this is a hassle.

Phase 5: Billing and data, platform by platform

Stripe subscriptions

Stripe lets you cancel a subscription at the end of the current billing period by setting cancel_at_period_end=true. That "allows the subscription to complete the duration of time the customer has already paid for" (Stripe Docs). You can also schedule cancellation for a specific date with cancel_at, or cancel immediately with optional proration.

A few details from the docs matter during a shutdown:

• Pending invoice items aren't removed automatically. You have to delete them manually so customers aren't billed for them.
• For metered prices, usage reported during the period is billed at the end of the period unless you clear it.
• Once a subscription is fully canceled, Stripe sends a customer.subscription.deleted webhook event. You can use it to trigger a confirmation email.

Apple auto-renewable subscriptions

Apple's help page says that before you discontinue a subscription, you should remove it from sale in App Store Connect "to stop additional sign-ups and renewals." It also says "a minimum of 31 days is required" between removing the subscription from sale and stopping the service, so monthly and shorter subscriptions can expire. You're also "required by the Paid Apps Agreement to provide the full amount of content to eligible subscribers through the subscription duration." For subscriptions longer than one month that you can't fully honor, Apple asks you to contact it (Apple Developer).

Some developers on Apple's forums report that renewals continued even after they removed availability in every territory (Apple Developer Forums). The behavior may depend on how you remove the subscription. Treat this as unsettled: check your renewal notifications after you make the change, and contact Apple if renewals keep happening.

For support, this means App Store subscribers often can't be refunded by you directly. Apple handles those refunds, so your saved reply should point customers to Apple's refund process instead of promising one yourself.

Data export and deletion

If you have customers in the EU or UK, the GDPR applies. Article 20 gives people the right to receive personal data they provided "in a structured, commonly used and machine-readable format" when processing is based on consent or a contract and is automated (GDPR Article 20). Article 17 covers the right to erasure (GDPR Article 17).

In practice, a self-serve export in a common format (CSV or JSON) answers most of these requests before anyone has to write in. Publish a deletion date and stick to it. If you're unsure what your obligations are, ask a qualified advisor. This post isn't legal advice.

Phase 6: Support after the lights go out

Email doesn't stop when the servers do. People come back months later because of an old backup, a bank statement they don't recognize, or a newly reinstalled device.

• Keep the support address working. Set an auto-reply that gives the shutdown date and links to the FAQ, and still check the inbox now and then.
• Keep the shutdown page online for as long as you reasonably can. A static page costs almost nothing to host.
• Keep answering store reviews. One-star "it doesn't work anymore" reviews will come in. A short, factual reply helps the next person who reads them.
• Set a fixed review schedule. Weekly at first, then monthly. A short, regular routine works well here, much like reviewing overnight support in a short daily session.

Where AI-drafted replies fit (and where they don't)

A shutdown means many similar questions that each need a polite, accurate answer, which suits drafting tools well. It's also a time when a wrong answer about refunds or deadlines does real damage, so a person should check every reply before it goes out.

SupportMe (currently in pre-launch) is built around that human-in-the-loop model. It drafts email and app store review replies in your writing style, learns from your edits, and never sends anything without your approval. Whatever tool you use, or none, the fact sheet from Phase 1 does the most for consistency. Every reply, drafted or handwritten, should match it.

Conclusion

A good sunset comes down to deciding first and communicating second. Set the dates, refund rules, and data policy before the announcement. Turn them into a public FAQ and saved replies. Close purchase paths, give at least 31 days' notice on every channel, and handle billing on each platform according to its documented rules. Answer messages by category instead of by arrival order, and keep a monitored inbox open after the shutdown. Customers will still be disappointed, but they'll have clear answers and enough time to move on.

References

• Apple Developer: Set availability for an auto-renewable subscription
• Apple Developer Forums: Remove from Sale vs. deleting an app
• Apple Developer Forums: Sunsetting an auto-renewable subscription
• Google Play Console Help: Update or unpublish your app
• Stripe Docs: Cancel subscriptions
• GDPR: Article 20, Right to data portability
• GDPR: Article 17, Right to erasure