Favors.dev
The short answer
Launch when something changes for the user, and size the launch to the change. For most founders that means a small launch every four to six weeks, a medium one each quarter, and one big one a year per product. If you run several products, stagger them so your audience hears about one thing at a time.
Most founders treat a launch as a rare, high-stakes event, and then wonder why one quiet launch day feels like a verdict. I run several products, and the habit that changed how I feel about launching was simple: stop treating it as an event and start treating it as a rhythm.
This guide is the cadence that follows from that. It covers what the platforms allow, which milestones are worth a launch (and which are not), how the answer changes with one product versus a portfolio, and a twelve-month calendar you can copy.
What does the one-shot launch mindset cost you?
It costs you every launch after the first, and it makes the first one worse. When you believe you get a single shot, you delay it until the product feels finished, you cram everything into one day, and you load that day with meaning it cannot carry. If it underperforms, you read it as a judgment on the product rather than as one data point.
It also hides the more useful truth about launches: most of the people who will ever see your product will not see it on launch day. Alex Hillman made the point well in How often do you launch?, arguing that every day your product exists, it is new to somebody who just found it. Launch day is a celebration, but the ongoing experience is where most of the audience actually meets you.
The practical fix is to shrink the stakes by repeating the act. If you launch regularly, no single launch matters much, and that is exactly why you can afford to learn from each one. Our continuous launch strategy explains how to make that the default instead of the exception.
What do the platforms actually allow?
Every launch venue has its own rules about repeats, and they are stricter than most founders assume. The pattern is consistent: the places with the most attention allow the fewest repeats.
| Where | What it allows | What that means for you |
|---|---|---|
| Product Hunt | The same product can post again after a gap, and only when the update is significant. The details are in the relaunch guide. | Plan one real PH launch a year per product, not a quarterly habit. |
| Show HN | Show HN guidelines say new features and upgrades generally are not substantive enough. A major overhaul is probably fine. | Save it for a rebuild or a first public release that people can try. |
| Launch directories | Most list a product once. Many allow an updated entry, and some let you resubmit after a major change. | Treat these as a one-time sweep plus a yearly refresh. |
| Your own channels | No rules. A newsletter, a changelog, your socials and your community can take an announcement any week. | This is where a smaller, more frequent cadence belongs. |
Two sources are worth reading directly. Hacker News publishes its Show HN guidelines, which say plainly that new features and upgrades generally are not substantive enough, while a major overhaul is probably okay. For Product Hunt, our relaunch guide walks through the waiting period and what counts as a significant update, with the date its policy details were checked. Policies like these change, so confirm the current rule on the day you plan to post.
The takeaway is not "launch rarely." It is that the big venues should be rare and the small ones should be frequent. If you are comparing the two main tech venues, our Show HN versus Launch HN comparison helps you pick which one a given milestone deserves.
Which milestones are worth a launch?
A milestone is worth a launch when a person who already knows your product would have a new reason to use it, or when a person who has never heard of it would understand it better. A bug fix passes neither test. A new use case passes both. Here is the honest list, ranked by the size of the launch each one deserves.
| Size | Milestone | What to do | Where |
|---|---|---|---|
| Big | First public release | Full launch: every platform that fits, a launch post, outreach | Product Hunt, Show HN if it can be tried, directories, communities |
| Big | A rebuild or a pivot that changes who it is for | Full launch, written as a new product story | Same list as above, plus everyone who used the old version |
| Medium | A major feature that opens a new use case | One post, one email, one channel push | Your newsletter, your socials, one community that fits |
| Medium | A pricing or plan change people have asked for | One post and one email | Your list and the pricing page |
| Small | A useful improvement, an integration, a free tool | A changelog entry and one short post | Changelog, socials |
| Not a launch | A bug fix, a redesign with the same functions, a small tweak | Ship it quietly | The changelog is enough |
The bottom row matters most. Calling a minor tweak a launch is how founders train their audience to ignore them. A useful rule is the one-sentence test: if you cannot explain the change to a returning user in one sentence they would care about, it is a changelog line. Our piece on changelog marketing shows how to make those quiet updates work for you without pretending they are launches.
What cadence fits one product versus a portfolio?
The right rhythm depends on how many products compete for the same audience and how much audience you have. Here is the pattern I use, from a single early product to a larger set.
One product, pre-revenue
A small public launch every 4 to 6 weeks; one big one at the first public release
You have almost no audience to tire out, and every launch is practice.
One product, growing
One big launch a year; a medium launch each quarter; small ones monthly
The medium launches feed the big one, which then has an audience to land on.
Two to four products
Stagger them so one product has a launch moment every month or two
Never launch two at once. A shared audience hears about one thing at a time.
A portfolio of many
Rotate: each product gets a quiet quarter, then a launch quarter
Keep a shared list of launch assets, so the fifth launch costs a fraction of the first.
A few things hold at every size. Launch the small things on your own channels first, where a miss costs nothing. Keep the big venues for the big milestones. And never run two big launches inside the same fortnight, because the second one will always borrow attention from the first.
Running a portfolio adds one more advantage: the work compounds. The screenshots, the one-line pitch, the launch post structure and the list of communities that fit carry from one product to the next, so each launch costs less than the last. If you are about to add another product to your stack, our guide to launching a second product covers what to reuse and what to start fresh.
What is launch fatigue, and whose is it?
It is two problems wearing one name. Your audience tires when every message asks for attention without offering anything new. You tire when every launch is built as a campaign from scratch. Both come from the same mistake: launching at one volume.
- Audience fatigue shows up as falling open rates, fewer replies and the same few people reacting every time. The fix is to make announcements proportional, so a small change gets a small message.
- Your fatigue shows up as launches you dread, delay or do halfway. The fix is a template: reuse the same structure, the same asset list and the same checklist every time.
- Cut the dead weight. Skip the launch that has no milestone behind it. A skipped month is not a failure, it is how the next launch stays worth reading.
- Rest is a scheduled item. Put a quiet month on the calendar, and treat it as time to fix things and talk to users instead of announce.
For the part that comes after the announcement, see what to do after your launch. Most of a launch's value is in the follow-up, which is another reason not to cram everything into a single day.
How do you build a launch calendar you can hold?
Start from the milestones, not the months. List what is actually going to change in the next year, size each one using the table above, and spread them so the big ones have room. This template is for one product and is meant to be edited, not obeyed.
| Month | Launch moment | Size |
|---|---|---|
| Month 1 | First public release | Big |
| Month 2 | Follow-up: what changed since launch day | Small |
| Month 3 | A feature your first users asked for | Medium |
| Month 4 | Directory sweep and review requests | Small |
| Month 5 | An integration or free tool | Small |
| Month 6 | Half-year write-up and a major feature | Medium |
| Month 7 | Quiet month: fix, listen, no announcements | Rest |
| Month 8 | A pricing or plan update, if users want one | Medium |
| Month 9 | Use-case page or case study from a real user | Small |
| Month 10 | Prepare the anniversary launch | Rest |
| Month 11 | Anniversary relaunch, if the update is significant | Big |
| Month 12 | Year in review and next year's plan | Small |
Three rules keep the calendar honest. First, every row needs a real change behind it; if you cannot name one, the row becomes a rest month. Second, review it quarterly and move things, because the product will not follow your plan. Third, tie each launch to a place people can see it. The Favors.dev launch calendar is built for that: you put the date on it, and other founders show up that day. It pairs with the launch directories guide for the evergreen places to list, and with shipping streaks for the habit of showing progress between launches.
Frequently asked questions
How often should you launch a new product?
Launch when something changes for the user, not on a timer. For most solo founders that means a small launch every four to six weeks, a medium one each quarter, and one big launch a year. If nothing worth announcing happened, ship quietly and keep the changelog current.
How often can you launch on Product Hunt?
Product Hunt allows a product to launch again when there is a significant update, and it applies a waiting period between posts. Because that policy has changed before, check the current rules on the day. Our Product Hunt relaunch guide walks through what counts as significant and what the platform asks you to describe.
Is launching too often bad?
It is when each launch asks the same people for the same attention without giving them anything new. Frequent releases are fine. Frequent big announcements are the problem. Keep the announcements proportional to the change: a changelog line for small things, a post for medium ones, a campaign for big ones.
How long should you wait between launches?
For big launches that use up a community's attention, such as Product Hunt or Show HN, wait until the product has changed enough that you could explain it to a returning user in one sentence. For smaller announcements on your own channels, a month is a sensible floor.
How should you launch several products without burning out your audience?
Stagger them and give each product its own audience where you can. Run one launch moment at a time, rotate which product leads, and reuse your launch assets so the work per launch falls. A product that is resting for a quarter is not neglected. It is on schedule.