Favors.dev
The short answer
The mistakes that sink a solo launch are structural, not tactical: launching to nobody, launching a demo, launching on five platforms at once, having no plan for the day after, treating the launch as your marketing strategy, and waiting until the product feels ready. Each one has a fix that takes a few hours, and the one "mistake" most lists warn about, launching without a budget, is fine.
Search for launch mistakes and you will mostly find lists written for companies with a marketing department: align your stakeholders, brief the sales team, book the launch event. None of it describes a launch where one person writes the code, the copy and the announcement, and the whole audience fits in a spreadsheet.
The mistakes below are the ones I see when that person launches. Every one comes with a fix you can start this week and a rough cost in time, because advice you cannot schedule does not get done. If you want the wider picture first, the pillar guide on getting your first 100 users covers where launch fits.
Mistake 1: Launching to an audience of zero
Launching with no one waiting is the most common solo mistake and the easiest to diagnose. A launch is an announcement, and an announcement needs people who will open it. If you post to a platform with no followers and no list, the post lands in front of strangers who have no reason to stop, and it disappears.
The test is blunt: can you name ten people who would read your launch post the hour it goes up? If not, the launch is not ready, whatever the product looks like. The fix is not a bigger launch. It is a smaller, earlier one, to people you can name. My guide to launching a SaaS with no audience walks through the whole route, and a waitlist is the simplest container for those first names.
Do this week instead20 minutes a day for 14 days
Start a list of 30 real people who have the problem you solve: replies you have received, people in communities you already use, founders you have helped. Message two or three a day with a direct question about the problem, not a pitch. By launch day you will have a group who already know what you built.
Mistake 2: Launching a demo and calling it a product
A demo works when you run it. A product works when someone else does. The gap between the two is where most disappointing launches live: sign-up works but the first task fails on a different browser, the empty state confuses people, or the core feature needs a step only you know about.
You cannot see this gap from the inside. You know where to click. The only way to find out is to watch a stranger try, ideally a handful of times, before the public does it for you. This is the same reasoning behind running a short private beta, which I cover in the guide to running a beta launch.
Do this week insteadOne afternoon
Ask one person who has never seen the product to finish the core task while you stay silent and take notes. Fix whatever stops them, then do it again with a second person. If both finish unaided, it is a product.
Mistake 3: Launching on five platforms in one day
It feels efficient to hit Product Hunt, Hacker News, Reddit, LinkedIn and your newsletter on the same morning. In practice you answer comments in five places, do none of them well, and burn every channel at once. Each community has its own norms, and each one expects the person who posted to be present.
The free launch channels are well known: Product Hunt and its upcoming pages, Indie Hackers, a handful of subreddits, and directories. Their value is not that they are free but that each gives you a separate window of attention. Used one at a time, you get five windows. Used together, you get one crowded one. The launch week playbook lays out how to stagger them across seven days.
Do this week instead2 hours to schedule
Choose the one platform where your first users already spend time and give it launch day. Put the others on the following days, one per day, with the post already drafted. Reply to every comment on the day you post.
Mistake 4: No plan for the day after
Launch day gets a checklist. The day after usually gets nothing, and it is the day that matters more. Attention falls quickly after the peak, and the people who showed up are at their warmest right then. If you do not reach back out, most of them never come back.
Treat launch as the start of a week, not an event. Thank the people who commented, ask the users who signed up what they were trying to do, and share one specific thing you learned. I wrote a full seven-day version in what to do after your launch, including a track for when the launch landed flat.
Do this week instead45 minutes
Before launch, block the next seven days on your calendar and draft three messages: a thank-you to commenters, a question to new users, and a short update post. On the day after, you are sending, not starting from scratch.
Mistake 5: Confusing a launch with a marketing strategy
A launch is one day. A strategy is what brings in users in month three, when no one is paying attention to your announcement. Founders who treat the first as the second spend months preparing a single spike and then have nothing planned for the flat line after it.
Paul Graham made the point plainly in his essay Do Things That Don't Scale: all you need from a launch is an initial core of users, and how well you are doing a few months later depends more on how happy you made those users than on how many there were. That is the right frame. The launch gets you the first users. What you do next is the strategy, and the go-to-market guide for solo founders covers how to build it.
Do this week instead1 hour to choose
Pick one channel you can repeat every week for a month, such as one post, one community reply session or one outreach batch. Write it down next to the launch date, so the plan continues past day one.
Mistake 6: Waiting for it to be ready
This is the quiet one. Nothing fails, so nothing tells you to stop. The date moves, a feature gets added, the landing page gets one more pass, and months go by while no real person has used the product. The cost is not the delay itself. It is that every week you wait is a week without the feedback that would tell you what ready means.
Do not confuse this with Mistake 2. Rough edges are fine. A product that cannot finish its core task is a demo. The line between the two is whether a stranger can complete the one thing you promise, and a written must-work list settles that without a debate.
Do this week instead30 minutes
Write the three things that must work for the promise to hold. Test them. If all three pass, set a date within two weeks and ship. Everything else goes on a list for after launch.
The one "mistake" that is actually fine: launching with no budget
Many launch checklists warn about inadequate funding. For a solo founder, that warning is mostly noise. The launch channels that work at this size cost nothing: communities, directories, direct messages, a personal network. Paid ads, press agencies and launch events are tools for teams with a budget and a repeatable offer. You have neither yet, and spending before you know what converts is how a small budget disappears.
Time is your real budget, and it is the thing the six mistakes above waste. If you have 20 minutes a day, put it into the list, the follow-ups and the user conversations. The case against paid acquisition at this stage is covered in why paid ads do not work for bootstrappers. One more caution from the research on failed launches: Harvard Business Review's piece on why most product launches fail frames the central challenge as getting attention for a new offering, which is a problem money alone does not solve.
The six-fix scorecard
Here are all six together. Read the middle column honestly. If the "tell" sounds like you, do the fix before you pick a launch date.
Launch mistakes scorecard
| Mistake | The tell | Do this instead | Time |
|---|---|---|---|
| Launching to nobody | You cannot name ten people who would open the launch post. | Build a list of 30 real names and message a few every day. | 20 minutes a day for 14 days |
| Launching a demo | Only you have ever finished the core task. | Watch one stranger do the core job start to finish, unaided. | One afternoon |
| Everywhere at once | Your plan has five tabs open on launch morning. | Pick one main platform and stagger the rest across a week. | 2 hours to schedule |
| No day-after plan | Your calendar is empty from the day after launch. | Block seven days and pre-write three follow-up messages. | 45 minutes |
| Launch as strategy | You cannot say where launch number two comes from. | Choose one repeatable channel and commit to it for a month. | 1 hour to choose |
| Waiting for ready | The launch date has moved twice and the list keeps growing. | Write a three-item must-work list and ship when it holds. | 30 minutes |
If two or more tells match, you are not behind. You are early, and early is the cheapest time to fix them. The launch day checklist is the right next read once the scorecard is clean.
The one problem a checklist cannot solve is the first mistake, the empty room. That is what Favors.dev is for. Members earn points by doing verified favors for each other, such as honest feedback, reviews and shares, and spend those points to get help with their own launch. Put yours on the launch calendar and you have people watching it who are not your friends and family.
Frequently asked questions
What are the most common product launch mistakes?
For a solo founder the common mistakes are structural: launching with no audience, launching a demo instead of a working product, spreading the launch across many platforms on one day, having no plan for the days afterward, treating the launch as the whole marketing strategy, and delaying it while waiting for the product to feel ready. Most of these are fixable in a week.
Why do product launches fail?
Launches usually fail because nobody who matters is paying attention when they happen, not because the launch itself was badly executed. A solo founder with no list, no early users and no follow-up plan has no one to notice the announcement. The remedy is to build a small group of interested people before launch day and keep talking to them afterward.
Is it a mistake to launch an unfinished product?
Launching with rough edges is fine. Launching something that cannot complete its core task is not. The test is whether a stranger can do the one thing the product promises without your help. If they can, ship it and improve it in public. If they cannot, you have a demo, and you should fix that first.
Should I launch on Product Hunt, Hacker News and Reddit on the same day?
Usually not. Each community has its own norms and each needs your attention for most of a day. Choose the one where your first users already spend time, give it your full focus, and spread the others across the following days. You get a fresh burst of attention each time instead of one thin spike.
How soon should I plan what happens after launch?
Before launch, not after. Attention is highest in the first day or two and falls quickly, so the follow-up messages, the replies to early users and the next piece of content should be drafted and scheduled ahead of time. Even 45 minutes of planning beforehand changes what you do on the day after.