How to relaunch your product — you don't only get one launch

You can relaunch the same product, and every major launch surface says so in writing. Product Hunt asks for six months between posts and a significant update. Hacker News treats a major overhaul as a legitimate new Show HN. BetaList hands every startup two slots on purpose. The “you only get one launch” rule that governs so much founder anxiety isn't a rule at all — it's a misremembered version of a much narrower one, and it costs indie founders more distribution than almost any other belief in this business.

What's actually true is more useful and more demanding: you get as many launches as you have things worth launching. The whole problem is telling those apart. This guide is the eligibility test I use — what counts, what each platform actually permits, and a three-way decision that ends with you shipping quietly, posting an update, or clearing the calendar for a real relaunch.

Can you launch the same product twice?

Yes — with conditions that vary by surface, none of which are “never again.” The clearest statement comes from Product Hunt's own help center on relaunching, which asks makers to wait at least six months between posts for the same product or company, requires a significant update alongside that, and describes exactly what happens if you try sooner: the system detects the relaunch, prompts you to describe what changed, and a human reviews it before approving the post. That is a permission process, not a prohibition.

So where did the myth come from? Three places, and each of them is a real thing that got over-generalized. The first is the six-month gap itself, which founders hear once, round up to “you can't relaunch,” and then repeat. The second is the launch-day adrenaline economy: a launch feels like a one-shot event because it is exhausting, so people treat the exhaustion as evidence of scarcity. The third is genuine — plenty of founders have relaunched badly, gotten a flat response, and concluded the platform punished them, when what actually happened is that they announced a redesign with a rocket emoji and the audience correctly declined to care.

The consequence of believing the myth is that founders sit on real news. I've watched people ship a mobile app, a full rebuild, or a repositioning that changes who the product is for — and post it as a tweet, because they “already used their launch.” That is a distribution asset thrown away out of superstition. The opposite failure is just as common and easier to spot: relaunching every six weeks until nobody opens the email.

What actually counts as relaunch-worthy?

A change is relaunch-worthy when it changes the answer to “who is this for and what does it do,” not when it changes how much work you did. Effort is not the unit. I've shipped six-week features nobody outside the product cared about and two-day changes that made an entirely new kind of person a customer. The second is a launch; the first is a changelog entry, no matter how tired I was.

The right-hand column is where most founders get into trouble, because everything in it feels significant while you're building it. A redesign in particular is the great trap: it consumes months, it's the most visible change you can possibly make, and it is the single example Product Hunt names as not qualifying. The reason is sound. A new UI changes the experience for people already using the product and changes nothing at all for the stranger who never got far enough to have an opinion about your UI.

One useful reframe: a relaunch needs a new promise, not new work. If the sentence you'd put on the launch page is the same sentence as last time with adjectives upgraded, you don't have one yet. If it's a different sentence aimed at a different person — “now it runs offline,” “now it's a Mac app,” “now it's for teams” — you do.

What are the relaunch rules on each platform?

Every surface has a different answer, and only some of them are written down. Here's what each platform actually permits, sourced from its own documentation where documentation exists.

Two rows deserve expanding. On Hacker News, the official Show HN rules draw the line at substance rather than novelty: new features and point releases generally aren't substantive enough, while a major overhaul probably is. Separately, the site FAQ permits a small number of reposts when a story hasn't had significant attention in the last year or so, and asks you not to delete and repost the same submission. The etiquette side of an HN launch — titles, the first comment, surviving the thread — is in the Show HN launch guide, and it applies unchanged to a second attempt.

BetaList is the interesting one, because its policy is explicitly a two-launch policy. BetaList's submission criteria state that each startup gets two opportunities to be featured — once pre-launch and once during launch — with at least a few weeks between them, and that products which launched a while ago or already picked up significant press coverage are out of scope. Read that as a design instruction: it is telling you to hold your second slot until you have an actual launch, not to burn it on the in-between. Where each of these sits in a full submission sequence is mapped in the startup launch directories guide, and the specific alternatives worth a second submission are in the Product Hunt alternatives roundup.

Ship quietly, post an update, or relaunch?

Three questions decide it, in order. Fail any one of them and you drop to the tier below — which is a demotion in volume, not in value. Most shipped work belongs in the quiet tiers, and founders who accept that get more out of the loud one.

And here are the three places you can land. The brightness is the point: each tier costs roughly ten times the effort and ten times the goodwill of the one before it.

The middle tier is the one nobody talks about and the one that solves most cases. “Post an update” is not a consolation prize; it's how you keep a product visible between launches without spending anything you'll need later. Product pages take updates. Directory listings take updates — refreshing your entry on the apps directory or the launch directories you already submitted to costs an afternoon and keeps a live page accurate. Communities take updates, if you're a regular rather than a visitor.

How do you tell the “what's new” story?

Lead with the new job the product can do, and never with the list of things you built. The changelog dump is the default failure mode of relaunch copy: eleven bullet points, each individually true, adding up to no reason for anyone to click. A stranger reading your relaunch has one question — what can I do now that I couldn't do before? — and the version numbers are not an answer.

Four moves that consistently work:

• Name what it replaces.“This replaces the spreadsheet you keep for X” orients people faster than any feature description, because it tells them which shelf you go on.
• Say what was wrong with v1 out loud.“The first version made you configure everything up front and most people quit at step two” buys more credibility than a paragraph of benefits, and it pre-empts the sharpest comment in the thread. Candor is the cheapest asset a solo founder has.
• Don't re-tell the origin story.The people who heard it the first time will skim, and the people who didn't are here for the product. One sentence of context, then the new thing.
• Ship one artifact, not five.A sixty-second demo of the new capability only — no logo reveal, no roadmap, no gallery of screens you redesigned. If the demo needs narration to make sense, the change isn't as clear as you think it is.

Then run it like a launch, because it is one. Everything in the launch-day checklist applies to a second launch unchanged, and if the update is big enough to justify more than a day, the five-day launch week works better on a relaunch than on a first launch — you already know which surfaces converted last time, so you can weight the week toward them instead of guessing. The Product Hunt mechanics themselves, including the relaunch request, are covered in the 2026 Product Hunt guide.

How often is too often?

The binding constraint isn't the platforms — it's your crowd. Product Hunt's six months is a floor you'll rarely hit anyway; the number that actually limits you is how many times a year you can credibly ask the same forty people to show up. My working answer, running several products at once: two real relaunch events a year per product is comfortable, three is the ceiling, and anything past that means I'm substituting announcements for progress.

That constraint is worth stating plainly because it's the part no platform policy covers. Every launch spends social capital. A first launch spends whatever you've banked from being useful to other people; a relaunch spends it again, from the same account, with less novelty attached. If you did nothing for anyone between launch one and launch two, there is no crowd — not because anyone is punishing you, but because there's nothing there to draw on.

This is the piece of relaunch strategy that no checklist fixes, and it's the reason I built Favors.dev. It's a founder marketing co-op with a points economy: you earn points by doing verified marketing favors for other founders — real testing, honest feedback, reviews from people who actually used the thing — and you spend those points to get help back. You can't spend what you haven't earned, which is exactly the discipline a relaunch needs. The months between launch one and launch two are when you bank it. Put the date on the launch calendar the way you would a first launch — the calendar doesn't care which number it is, and neither do the people who show up.

Frequently asked questions