River
Y CombinatorBacked by Y Combinator

Product & DesignFree

Deprecation Notice Generator and Email Kit

Say what is being retired, when, and what replaces it, and get the public notice, customer email, reminders and a changelog entry.

Context to provide

River's deprecation notice generator turns three facts, what is being retired, when, and what replaces it, into the full set of messages a retirement needs. You get the public notice for your docs or blog, the first customer email, reminder emails timed to your dates, a changelog entry, a short in-product banner, and answers your support team can paste. Every message carries the same dates and the same replacement, so customers never hear two versions of the story.

Most deprecation templates give you one announcement and stop. The harder part is staying consistent over months: the reminder that goes out eight weeks later has to say exactly what the first email said, and the support answer has to match both. River writes them together from one dates table at the top of the document. If you still need to decide who is affected and how long to give them, the feature sunset plan works that out from usage first.

This is for product managers retiring a feature, founders shutting down an old plan or integration, and teams retiring an old version of an API that customers' developers still call. Pick who has to act, developers or everyday users, and the wording changes with them: exact changes for developers, plain what-changes-for-you wording for everyone else. For a bug rather than a planned change, the customer bug notice is the better fit.

A deprecation has two dates, not one

A deprecation has two dates, and customers confuse them. The first is when the old thing is officially on its way out: it still works, but nothing new will be built on it. The second is when it stops working. The IETF, which publishes internet standards, gives each date its own signal for web services: RFC 9745 defines a Deprecation header, RFC 8594 a Sunset header, and the shutdown date must never come before the deprecation date.

Every message should state both dates in the same words. Deprecated on March 3, switched off on September 30, leaves no room for a reader to assume the feature disappears tomorrow, or that it will limp on forever. Then say what replaces it, what the customer has to do, and roughly how much work that is. A notice that only says migrate to version 2, without saying what changes, forces every customer to find out alone, and most of them will write to support.

Here is an illustrative timeline for retiring a reporting feature. Announce in March with the public notice and the first email. Stop new sign-ups in June, with a reminder to everyone still using it. Send a final reminder two weeks before the switch-off on September 30, and a short confirmation afterwards. Each message repeats the same two dates and links the same how-to guide. When the replacement ships, the feature announcement kit handles the launch side of the story.

How it works

  1. Describe the change

    What is being retired, what replaces it, the dates you have, and who has to act.

  2. River drafts the set

    Notice, emails, reminders, changelog, banner and support answers, all built from one shared dates table.

  3. Confirm the gaps

    Anything you did not say, like a reason or a migration step, is marked for you to confirm.

  4. Adjust in chat

    Move a date, soften the tone, or add a personal message for your largest customers.

What you get

  • A dates table at the top, so every message repeats the same deprecation and switch-off dates
  • A public notice for your docs or blog stating what changes, when it happens, and why
  • A first customer email plus reminder emails timed to the dates you actually gave
  • A changelog entry, a short in-product banner, and ready answers for your support team
  • Exact changes for developers, or plain what-changes-for-you wording for everyday users of the feature
  • Gaps such as a missing reason or migration step marked to confirm, never invented

Common questions

How much notice should I give before removing something?

Enough for the slowest affected customer to make the change, which depends on the work involved. Changing a setting may take weeks; rebuilding an integration can take months. Check your contracts and published policies first, since some promise a minimum period. River uses the dates you give and flags any window that looks short for the work described.

What is the difference between deprecated and removed?

Deprecated means the feature still works but is on its way out: no new work will go into it and customers should move. Removed, or sunset, means it has stopped working. Good notices give both dates every time, because customers who only hear deprecated often assume either that nothing has to happen yet or that it already broke.

Should the notice say why we are retiring it?

Yes, in a sentence, and honestly. Customers accept a change more readily when they can see the reason, for example that the old version cannot support a security feature they asked for. River uses the reason you give. If you do not give one, it leaves a marked gap rather than inventing a reason that might not be true.

Can it write a message for our biggest customers?

Yes. After the main set is written, ask in chat for a personal email to a named account, and include what you know about how they use the feature. River keeps the same dates and replacement as the public notice, and adds an offer of help that you can adjust before sending it yourself.

Does River send the emails?

No. River writes the notice, emails and other messages into a document for you to review, edit and send through your own email or help desk tools. Nothing goes to a customer from River. Copy each message into the tool you already use, so your sending address, unsubscribe settings and tracking stay exactly as they are.

What if we are retiring an API, not a screen?

Choose developers as the people who need to act. The notice then lists exactly what changes, item by item, from what you describe. The document also adds a short note your engineers can use to announce the same dates inside the API itself, with the standard deprecation and sunset signals.

Deprecation Notice Generator and Email Kit

Describe what you need, add any files you have, and your workspace opens with the work already underway.