How to get your first users

The first ten users and the first hundred are different problems with different solutions, and nearly every stalled launch is someone trying to solve the second one before the first. Ten is manual: conversations, one at a time, in places where your problem is already being discussed. A hundred is repeatable: the same motion, run again, because you now know which sentence makes people say yes.

The order matters more than the tactics. Build a repeatable channel before you know what makes someone care and you get a machine that reliably delivers strangers to a message that doesn't land - and because the mechanics work, you'll spend months optimising the wrong half.

Ten users is a number you can reach by hand in a week if you're willing to do work that doesn't scale. That constraint is a feature: doing it manually produces the thing you actually need at this stage, which isn't users but language - the specific way real people describe the problem, the objection that comes up every single time.

You cannot get that from a channel. A landing page tells you a conversion rate, not why. A cold email sequence at 200 sends tells you a reply rate, not that four of the five repliers misunderstood the product in the same way. Ten conversations tell you both, fast enough to change the product while changing it is still cheap.

The switch to the second problem happens when you can predict the response. When you know roughly what someone will say before you send it, you have a message worth putting behind a repeatable process. Until then, scale just multiplies your uncertainty.

There is one durable principle for finding early users: go where people already describe your problem out loud, unprompted, without knowing you exist.

This sounds obvious and is almost never what people do. The default instinct is to announce the product to an audience - your followers, a launch site, a directory - and hope some fraction of them have the problem. That's backwards, and it's why launches produce spikes with no retention. Going where the problem lives inverts the odds: everyone there self-selected by complaining about the thing you fixed.

How to actually find those places

• Search the complaint, not the category. Not "invoicing software" but the sentence a frustrated person types at 11pm: "why does my accounting tool round VAT wrong". The pages that come back are the conversation.
• Follow threads, not platforms. One active thread with forty people arguing about your problem beats a subreddit of 400,000 who mostly post memes.
• Check where competitors get complained about. Review sites, support forums and "alternatives to X" discussions are dense with people already shopping, already annoyed, already articulate about what's missing.
• Ask your first three users where they'd have looked. The cheapest research available, and it routinely surfaces a venue you'd never have found.

If you don't know which venue type fits, the channel picker narrows six options to the two or three worth a month of your attention.

This is the fear that stops most technical founders cold, and it's reasonable - the internet is full of people doing it badly. The distinction is simpler than it feels, and testable in five seconds.

The rest is mechanical. Answer the question that was actually asked, in full, before mentioning anything you built. Say plainly that you made it - communities punish undisclosed self-promotion, not self-promotion. Post from an account with a history rather than one created that morning. Don't paste the same paragraph in twelve places; moderators pattern-match on that faster than users do.

Why this works matters, because "be helpful" sounds like a platitude and isn't. Unhelpful promotion fails on its own terms long before anyone gets offended: it gets removed, downvoted or ignored, and converts at roughly zero. Being useful in public isn't a moral position here - it's the only version that produces users.

Two things are genuinely spam and no framing rescues them: posting where your problem isn't being discussed, and automating any of this. Both fail immediately and cost you the venue permanently.

The principle is constant; the venue isn't. Treat this as a starting hypothesis for your first fortnight, not a ranking - the right answer is whichever venue is genuinely active for your specific problem.

Not worthless. Poorly ordered. Launch sites are amplifiers, not sources - they multiply attention you can already generate, and any multiple of zero is still zero.

The specific failure: a launch day is a one-time event you can only spend once. Spend it before you have anyone and nobody turns up for you, nobody knows what to say about you, and the traffic that does arrive hits an onboarding no stranger has ever tested. You also get the wrong audience - people who evaluate products as a habit, not people with your problem - which produces feedback that sounds authoritative and predicts nothing. And the traffic doesn't persist: a spike with no capture mechanism leaves you where you started, minus the launch you can't repeat.

The version that works is later: once you have users who'll show up, an onboarding that has survived people you didn't coach, and a specific claim rather than a general announcement. Then it amplifies something real. Before that, it's a substitute for the ten conversations you didn't have.

At ten users nothing is statistically anything. You're collecting sentences, not rates - so measure what's meaningful at n=10 and ignore what isn't.

• Where each one came from, written down by hand. Not "organic" - the specific thread, message or person. Ten rows in a text file beat a dashboard here, because the dashboard can't tell you which sentence did the work.
• What they said before they agreed. Verbatim. The phrasing that repeats across three users is your headline, and you won't invent it yourself.
• How many completed the core action unaided. Signups are not usage. What matters is how many reached the thing your product does without you sitting next to them.
• How many came back within seven days unprompted. The most informative number at this scale - unprompted return is the only early signal that isn't politeness.
• How much hand-holding each needed. If everyone required a personal walkthrough, you have an onboarding problem, and it will cap everything downstream.

Explicitly ignore for now: conversion rate, cost per acquisition, traffic totals, and anything expressed as a percentage of a number smaller than fifty. Those become real at the first-hundred stage. Quoting them at ten users is how founders talk themselves into believing a channel works.

The manual stage is faster than founders fear; the repeatable stage is slower than they hope. Ten users from communities where your problem is genuinely discussed is a week or two of unglamorous work. Turning that into a hundred takes months, because you're testing whether what worked by hand survives being systematised - and often it doesn't first time. Nobody can tell you in advance which channel will work for your product, and anyone who does without asking what you sell and to whom is guessing. The process above isn't a shortcut around that uncertainty; it's the cheapest way to resolve it.

The channel picker asks about your product, your price and who actually buys, then names the two or three channels worth your first month and the ones to ignore. It's built to stop you spreading one week of effort across six places and learning nothing from any of them.

Or get the 30-day post-build playbook Send it