Launching a side project when nobody knows who you are

Most launch advice is written by people with a mailing list. "Tell your audience" is excellent guidance if you have one, and useless if you are a developer who has been building something quietly for four months and knows roughly nine people who might care.

This is the version for that situation.

Lower the definition of launch

A launch is not an event. Treating it as one puts everything on a single day, and a single day with no audience produces a single day of nothing, followed by the conclusion that the product is bad.

The product is probably fine. The distribution has not started yet.

Think in terms of the first hundred people instead. A hundred is enough to tell you whether the thing is useful, which is the only question that matters early. It is also achievable without anyone knowing who you are.

Go where the problem is discussed, not where products are posted

The instinct is to post the product somewhere. The thing that works better is finding where people describe the problem, in their own words, and being useful there.

Search for the phrase someone types when they have the problem you solve. Not your product category, the actual complaint. Forums, subreddits, Discord servers, Stack Overflow questions, issue threads. Read for a while before you post anything.

Then answer questions properly, and mention what you built only where it genuinely answers the question. This converts at a rate that looks unbelievable compared to broadcasting, because you are talking to someone who has already described the need out loud.

It is slow. It is also the only part of this that reliably works with no audience.

Get listed where the intent is

Directories and comparison pages work for the same reason: someone is already looking for a tool like yours. They are not a substitute for the work above, but they run in the background permanently, and they cost you an hour once.

Prioritise the ones a human maintains. A listing on a site where every submission is published automatically sits in a pile of ten thousand. A listing on a site where someone reads submissions sits in a much shorter pile, on a page that has a chance of ranking.

We wrote separately about how to prepare a submission properly, because doing it once well beats doing it forty times badly.

What to skip

Buying an audience. Paid traffic to an unproven product tells you what your ad copy converts at, not whether the product is good.

Launch platforms as your only plan. A good day on one is genuinely useful. It is also one day, and it favours people who arrived with an audience, which is the thing you do not have.

Cold outreach at volume. Two hundred identical emails is a rounding error of replies and a permanent mark on your domain. Ten researched ones outperform it.

Waiting until it is ready. It will not be. Ship the version that solves one problem completely rather than five partially.

Write down what happens

Whatever you try, record where the people came from and what they did. Not analytics dashboards, just a note: posted in X, got 40 visits, 3 signups, one person emailed about a missing feature.

After a month you will have a short list of the two or three things that actually moved, and you can stop doing everything else. Nobody can hand you that list. It is specific to your product and the people who want it.

The honest timeline

The first hundred people take longer than you expect and arrive from places you did not plan for. The second hundred take a fraction of the time, because by then you know which two channels work.

Most people quit between those two points, which is the entire reason the second hundred is easier.

When you are ready to be found by people looking for what you built, submit your tool. It is free, a person reads every listing before it publishes, and the page stays there long after launch week is over. You can also browse the highlights to see what else has gone up recently.