How do you get the first users for a product?

Not by broadcasting a launch to strangers, but by going where the people with the exact problem already are and showing them the specific solution. The first users come from being genuinely useful to a narrow group who has the problem — direct outreach, communities where they gather, and content that ranks so problem-aware people find it over time. Early on you do things that don't scale (talk to people one by one) because the goal isn't volume, it's the first handful of real users who have the problem and will tell you the truth.

Why is getting the first users so hard?

Because there's no momentum yet — no social proof, no word of mouth, no search presence, nobody vouching for you. Every later user is easier because someone came before; the first ones have none of that scaffolding. That's why broadcasting a launch rarely works for the first users: strangers have no reason to trust an unknown product. The first users have to come from targeting people who have the problem badly enough to try something new, and reaching them where they already are rather than hoping they find you.

Should you do things that don't scale to get early users?

Yes. Early on, the point isn't efficiency — it's learning and traction, and both come from close contact with real users. Reaching out individually, onboarding people personally, joining the exact communities where the problem lives: none of it scales, and that's fine, because you only need a handful of real users at the start, and those users teach you what the product actually needs. You industrialize distribution later; at the very start, unscalable and personal is exactly right.

How I Get My First Users as a Solo Builder

The standard first-user advice is "launch": pick a day, post everywhere, watch the signups roll in. The first users really are the hardest — no momentum, no proof, no one vouching for you — and a launch to strangers is the worst tool for the job, because strangers have no reason to trust an unknown product. My approach is the opposite: go where the people with the exact problem already are, show them the specific solution, and let content that ranks bring problem-aware people in over time. With Delivery Sheet and Listemizde the first users didn't come from shouting to everyone; they came from being useful to a narrow group who had the problem badly enough to try something new.

The cold-start problem

Every user after the first is easier because someone came before — social proof, word of mouth, a search result, a name-drop in a thread. The first users have none of that scaffolding. That's the actual difficulty: not that the product is weak, but that there's no momentum yet, and momentum is most of what makes later users cheap. So the first-user problem is really a trust-without-proof problem, and you don't solve it by casting wide to people who don't have the problem — you solve it by going to the ones already primed to.

Don't broadcast — go narrow

"Launching" to everyone is the seductive wrong move for the first users. The first users aren't hiding in the general public; they're clustered wherever people with your exact problem already gather. Go there.

The instinct is to launch: one big announcement to as many people as possible. But a broad audience is mostly people who don't have the problem, and to them the product is noise. The first users are concentrated — they sit in the specific communities, forums, and threads where the problem already comes up by name. Going narrow to where the problem lives beats going wide to where it doesn't, and it isn't close.

Be where the problem already is

So I find where people already talk about the problem the product solves, and I show up useful — not pitching, helping, and mentioning the solution only where it actually fits. The people in that conversation are pre-qualified: they have the problem right now, enough to be discussing it in public. That's a far warmer start than a stranger scrolling past a launch post. It's content-led distribution done by hand — meet problem-aware people — before there's enough writing to meet them for you. Listemizde had no paid rankings to buy its way in front of anyone; the only door was being genuinely useful where the problem already lived.

Content is the compounding engine

The hand-work gets the first users; writing is what turns them into a repeatable flow. Content that answers what your future users are searching keeps pulling problem-aware people in long after you publish — so the handful you find by knocking on doors is followed by a steady trickle who arrive through search. The manual work starts it; the content compounds behind it. This site is that arrangement in the open: writing that ranks, with the products one click away.

Do things that don't scale

Early on I do the unscalable on purpose: reach out one by one, onboard people myself, sit in the exact conversations. None of it scales, and that's correct — at the start I don't need scale, I need a handful of real users who have the problem and will tell me the truth. Those users teach me what the product actually needs, which beats a thousand signups who bounce and say nothing. You industrialize distribution later; at user one, personal and unscalable is the right tool, not a compromise.

What usually goes wrong

Launch-and-pray. A big broadcast to strangers who have no reason to trust an unknown product, then silence.
Too broad. Targeting "everyone" instead of the narrow group who actually has the problem.
No distribution plan. Building with no honest answer to "where are the people with this problem?" — the silent launch.
Skipping the unscalable work. Refusing to do the hand-to-hand early outreach because it "doesn't scale," and never getting the momentum to start.

Go where the problem already lives, be useful there, do the unscalable early work, and let content compound behind it — and the first users come from being genuinely helpful to people who have the problem, not from broadcasting to people who don't. The first ones are earned narrowly; the rest follow the trail they leave. It's distribution at its coldest and most personal, and there's no shortcut around the hand-work at the start.

Part of Building AI Products. See also how I think about distribution as a solo builder and why I built Delivery Sheet. The newsletter sends one practical build lesson every two weeks.