Favors.dev
The short answer
To announce a rebuild, tell existing users what it means for them before you tell anyone what is new: what happens to their data, what breaks, whether the price changes, and when they have to switch. Then say plainly, in one sentence, what the old version got wrong, and say what you kept. Save the launch-style announcement for the public, once the people who use the product every day already know.
A rebuild is the hardest thing to announce, because the honest version of the message is that the thing people have been using was not good enough. The dishonest version is a changelog entry that pretends nothing happened. Both lose. The first sounds like a confession, the second sounds like a cover-up, and users can tell which one they got.
The temptation is to skip the awkward part and go straight to the exciting part. Resist it. The people reading most closely are not prospects. They are the users with real data in the old version, and they are reading to find out what you are about to break.
Why is a rebuild not a feature launch?
A feature launch adds something and asks people to notice. A rebuild replaces something people already rely on and asks them to trust you with it. The first is a marketing event. The second is a migration, and the announcement is the migration guide with a headline on it.
That is also why rebuilds are risky in the first place. Joel Spolsky's classic essay Things You Should Never Do, Part I calls rewriting from scratch the single worst strategic mistake a software company can make. Whether or not you agree, it sets the bar for the announcement: if you paid the price of a rebuild, users need to see what they got for the wait. If you are still deciding whether the change is big enough to announce at all, the relaunch readiness scorecard gives you a ten-second test.
How do you admit what v1 got wrong without trashing it?
Name one specific failing, in the user's terms, and say why a patch could not fix it. "It was slow, and every report made it slower" works. "The architecture could not scale" does not, because it describes your problem instead of theirs.
Then say what you kept. Users read a rebuild announcement asking one question: is the thing I liked still there? Answer it before they have to worry. The version of the message that survives is the one that says the old product earned its users, that it hit a wall, and that here is what changed to get past the wall.
Three things to leave out: blaming the old code, blaming the people who wrote it (even if that was you), and any sentence containing "legacy". The word tells a paying user you think of their product as a burden.
Before and after: a rebuild announcement teardown
Below is a first draft of a rebuild announcement next to its rewrite. The product is an illustrative example written for this post, not a real company. The problems in the first draft are the ones that show up in real rebuild announcements again and again, and the notes explain what each fix does.
| Part | First draft | Rewrite | What changed |
|---|---|---|---|
| Opening line | We are thrilled to announce the all-new [Product] 2.0! | [Product] has been rebuilt from scratch. Here is what changes for you. | The first version celebrates. The second tells an existing user this concerns them, and that the details follow. |
| The admission | Our old platform served us well, but it was time to evolve. | The first version was slow, and every report you ran made it slower. We could not fix that without starting over. | This is the paragraph that worked. It names one specific failing, in the user's terms (slow), and says why a patch was not enough. It does not blame the old code or the people who wrote it. |
| What v1 got right | (Not mentioned.) | The parts you liked, the boards and the shortcuts, are unchanged. We rebuilt everything under them. | A rebuild that keeps the parts people loved is the real headline. If you skip this, users assume you threw all of it out. |
| The migration | Your data will be seamlessly migrated. | Your boards and history move over automatically on [date]. Comments older than [date] and custom fields do not, and you can export both today. | This is the paragraph that had to be rewritten. "Seamlessly" is a promise with no edge, and the first user whose custom fields vanished would have quoted it back. |
| The ask | Try it now and let us know what you think! | Try it on a copy of your account first. If something is worse than before, reply to this email and I will look at it myself. | One ask that treats the reader as a person with real data at stake, and a real reply path. |
Look at the pattern across all five rows. Every first-draft line is about the founder: thrilled, evolved, seamless, let us know. Every rewritten line is about the reader: their data, their reports, their copy of the account. That shift is most of the work. If you only have time to fix one thing in your own draft, fix the migration paragraph, because it is the one users screenshot.
What do existing users need to know first?
Five answers, in the first screen of the message, before any feature tour. If a reader has to scroll to find out whether their data survived, they will assume the worst and read the rest defensively.
01Is my data coming with me?
Say yes or no, and how. If something does not migrate, name it. Silent gaps are what people find on day two.
02What breaks?
Integrations, API endpoints, shortcuts, saved views, embeds. List them, even if the list is short.
03Does my price change?
Say so in the first screen. If it does not, say that too, and for how long.
04Do I have to switch, and when?
A date, and whether the old version keeps running until then.
05What if the new version is worse for me?
A way back, an export, or a refund. Something a person can actually do.
Write these into a dated section people can find again, and keep a running list of what changed. The Keep a Changelog convention, with its separate Added, Changed, Deprecated, Removed and Fixed groups, is a good skeleton for the detailed version. Link to it from the announcement so the email itself can stay short.
The order in which people hear matters as much as the wording. Paying customers and anyone with data in the old version hear first, privately. The same ring-by-ring order in how to announce a pivot applies here, because a rebuild changes what users depend on just as a pivot does.
How do you turn a rebuild into a launch event?
Make the rollout gradual for users and the announcement a single moment for the public. Existing users get a runway. Everyone else gets a dated event they can react to. The legitimate version of a relaunch is one where the product is genuinely different, and the three rollout shapes below cover most cases.
| Rollout | When it fits | The catch |
|---|---|---|
| Big-bang switch | Small product, few users, the old data model maps cleanly | Everything breaks on one day. Only works with a tested migration and a way back. |
| Opt-in beta | A meaningful group of users with real data and habits | Two versions to run. Set an end date or the beta becomes permanent. |
| Side-by-side, then sunset | Paid products where the change alters how people work | The most expensive to run and the kindest to users. Announce the sunset date on day one. |
Once existing users are through, the public launch is a normal relaunch: pick a day, pick the channels, and tell the story of what changed. The plan for that side lives in how to relaunch on Product Hunt and the complete guide to relaunching a product. Lead the public post with the new experience and give the rebuild story one paragraph. Strangers care that it is faster, not that it took a year.
A rebuild also resets your public presence. Update your app listing on the same day so the description, screenshots and links match the new product. Then let a fresh set of eyes in. On Favors.dev, a founder marketing co-op with a points economy, founders earn points by doing verified favors for each other, including trying a relaunched product and leaving honest feedback. Those are people who never saw v1, so they judge v2 on what it is.
When should you not announce a rebuild at all?
When users cannot tell. If the interface, the data, the behavior and the price are all unchanged, the rebuild is an internal engineering fact. Announcing it asks people to celebrate work they will never see, and it sets an expectation of improvement that nothing visible backs up.
Ship it quietly and put one line in the changelog. Then hold your announcement for the first thing the rebuild makes possible: the feature that was too painful to build on the old foundation. That is a launch users can feel, and it earns you the credit for the rebuild without having to explain it.
Frequently asked questions
How do you announce a rebuild of your product?
Lead with what it means for existing users: what happens to their data, what breaks, whether the price changes, and when they have to switch. Then say plainly what the old version got wrong, without blaming it, and keep everything the old version did well. Save the launch-style announcement for the public, after the people who use the product every day already know.
How do you announce v2 of a product without insulting v1?
Name one specific failing in the user's terms, like slowness or a missing workflow, and say why a patch could not fix it. Then say what you kept. Users forgive an honest reason. They do not forgive spin about an old version they have been paying for.
Should you announce a complete rewrite or just ship it quietly?
Announce it only if users can see or feel the change: a new interface, moved data, different behavior or pricing. If nothing they touch has changed, a rewrite is an internal fact and a changelog line is enough. Announcing invisible work asks readers to care about your engineering.
What should a v2 announcement email include?
The change and the date up front, one honest reason, what happens to the reader's data, what does not carry over, how to go back or export, and a reply address that reaches a person. Leave the feature tour for a second message.
Is a rewrite a good idea in the first place?
Often not. Joel Spolsky called rewriting from scratch the single worst strategic mistake a software company can make, because it stalls shipping while competitors move. If you rebuilt anyway, the announcement has to show users what they gained for the wait.