The Tool Worked. Nobody Cared.
No bugs. Clean UI. Did exactly what it promised. Three weeks, zero signups. The instinct in that moment is always the same: add a feature. Fix the onboarding. Rewrite the landing page copy. None of that was the problem.
The problem was that the tool had no audience waiting for it. It was built in a vacuum, then launched into silence, and silence got misread as a verdict on the product when it was really a verdict on the sequence. Build first, distribute second, is the default move for anyone who came up as a developer or operator. It’s also backwards.
Distribution First, Build Second
The fix isn’t a growth hack. It’s a sequencing change: find the audience that already exists, prove they want the thing, and only then finish building it. This is not a new idea — Paul Graham has been telling founders to do things that don’t scale for two decades, and Andrew Chen’s entire framework for early-stage products is built around solving the cold start before the product is even done. The version below is the tactical checklist for doing it with an AI tool specifically.
Step 1: Find where the complaint already exists
Before you touch code, go find the threads where people are already venting about the exact problem your tool solves. Reddit search, X/Twitter advanced search, niche Slack and Discord communities, LinkedIn comment sections under posts in your category. You’re not looking for people who might want your tool — you’re looking for people who are already typing out their frustration, unprompted, for free. That’s a validated problem statement sitting in public.
Step 2: Reply with the insight, not the pitch
Don’t drop a link. Don’t mention your tool. Answer the actual question or give the actual fix in the reply, the same way you’d answer a friend. This does two things: it builds a track record of you being useful in that specific problem space, and it gets you remembered without you asking for anything. If your reply is genuinely good, people will ask what you’re working on — that’s your opening, not your headline.
Step 3: Collect the DMs before the feature is done
When someone asks, tell them the truth: you’re building something for exactly this, it’s not done, and you’d like to send them early access. Get the DM, the email, whatever. You’re not selling a finished product — you’re building a list of people who raised their hand for a specific pain point, which is worth more than a thousand cold landing-page visitors.
Step 4: Let the waitlist prove demand
Set a real number before you build another feature. If you can’t get [X] people on a waitlist from genuine problem-thread engagement in [X] weeks, the issue isn’t your onboarding flow — it’s that the audience doesn’t exist where you’re looking, or the problem isn’t painful enough to act on. That’s information a working prototype can never give you, because a working prototype answers “can this be built,” not “does anyone want it.”
The 4 Rules After 51 Posts, 56,487 Reached
The pattern that separates posts that get replies from posts that get scrolled past is almost always the same four things, and it took a run of 20 posts reaching 22,122 people with zero comments to see it clearly:
- Specificity over scope. “I built an AI tool for founders” gets ignored. “I built a tool that turns a 40-minute sales call transcript into a follow-up email in 90 seconds” gets a reply.
- The hook is the problem, not the product. Open with the pain the reader already has, not the feature you shipped. The product shows up as the resolution, not the headline.
- One insight, not a feature list. A post that teaches one real thing outperforms a post that lists everything the tool does. Save the feature list for the DM.
- Reply before you post. The posts that reached the most people were preceded by weeks of replying in other people’s comment sections, not by posting cold into a feed with no existing relationships.
None of this replaces a good product. It replaces the assumption that a good product markets itself. If you’re also worried the tool itself won’t hold up once people show up, that’s a separate and legitimate concern — worth reading alongside this is what actually makes an AI tool defensible once the audience is real.
Build Second, On Purpose
Once the waitlist proves the demand, the build phase changes completely. You’re no longer guessing at features — you’re building exactly what the DMs told you they needed, for people who already said yes before you asked. The pitch also gets easier, because you stop trying to explain the automation and start describing the outcome those people already told you they wanted; that shift is covered in detail in sell the outcome, not the automation.
And if you’re tempted to treat the AI model itself as the moat instead of the audience and distribution you built to reach it, it’s worth reading why that’s a fragile bet in your AI startup is a tenant, not a company. The model can be replicated by anyone with an API key. The list of people who already told you they have this problem cannot.
The last thing you built that nobody used probably didn’t fail because it wasn’t good enough. It failed because it was finished before anyone was waiting for it. Flip the order next time.