How to Get Your First 10 Users for a Side Project

Getting your first 10 users is a list-building job, not a marketing one. Sit down for one hour and write ten specific humans into a table: who they are, where you found them, and what they already said publicly about the problem your project solves. Then send ten separate messages, each one referencing the thing that person actually wrote. That is the whole method. It works without a launch, an audience, a budget, or a single warm introduction, because every name comes from a public place where somebody already described your problem out loud.

Most advice on this subject assumes you can email six former colleagues and ask for intros. If you built something over three weekends and nobody in your contacts has the problem, that advice has nowhere to start. This post starts from a blank page.

Why is ten the right first number?

Ten is the number where the work stays personal. At ten, you can write every message by hand, remember every reply, and still name each person a month later. The moment you go past that, you start batching, and batching is where the useful signal dies.

Ten is also honest about what it can tell you. It will not tell you your retention rate or your conversion rate. One confused person out of ten is not "10% of users are confused", it is one confused person, and treating it as a percentage is how solo builders talk themselves into rewrites nobody asked for. What ten does tell you is whether the thing works at all in someone else's hands, whether your first sentence lands, and whether anyone opens it twice without being asked. Those three answers are worth more than any dashboard you could build at this stage.

There is a practical floor here too. If you are shipping an Android app on a personal developer account created after November 13, 2023, Google requires a closed test with at least 12 opted-in testers held continuously for 14 days before you can apply for production access. Ten real humans who care is most of the way to a requirement you will hit anyway. On the Apple side, TestFlight lets you invite up to 100 internal testers and up to 10,000 external ones, so the platform is not the constraint. Finding ten people who will actually open the build is.

Where do you find ten specific people, by name?

You are not looking for an audience. You are looking for ten individuals who have already, in writing, in public, complained about the thing you fixed. Those people exist for almost every project, and search engines index them.

The places that reliably produce names:

• Forum and subreddit threads asking your exact question. Search the phrasing a frustrated person would use, not the phrasing a marketer would. Everyone in that thread, including the commenters, is a candidate.
• GitHub issues on adjacent tools. Somebody who filed "feature request: batch export" on a competing project is telling you what they need in their own words, under a permanent handle.
• One-star and three-star reviews of the app you are replacing. The three-star ones are better. They stayed long enough to be specific.
• Discord and Slack help channels for the tool your project sits next to. Read the last two weeks of #help and you will find the same question asked four ways.
• Replies under a build-in-public post. Anyone who has commented on someone else's version of your project is warm by definition.
• Your own inbox and DMs. The person who asked you a question about this topic six months ago counts, and you have forgotten them.

Here is what a real list looks like when it is built from scratch in one sitting. The identities are placeholders standing in for the kind of person each slot produces, because the point is the sourcing pattern, not the names.

#	Where the name came from	What you already know about them	The ask
1	Posted the subreddit thread "is there anything that does X without a subscription?"	Wants X, will not pay monthly	"You posted about X. I built the free version. Would you tell me if it does what you meant?"
2	Top comment on that same thread	Described their workaround in detail	"Your spreadsheet workaround is basically what I automated. Worth five minutes?"
3	Filed a GitHub issue on a competing library asking for the feature you shipped	Technical, reads changelogs	"Saw your issue on the other repo. Mine does this. Fair warning, it is rough."
4	Left a three-star review saying the paid tool is "great but slow on big files"	Has real data, hit a real ceiling	"Does yours choke over 50MB too? Mine handles it. Would you try it on a real file?"
5	Asked the same question twice in a Discord #help channel	Actively stuck right now	Answer their question first, in public, then mention the tool once
6	Wrote a blog post about doing this manually	Has an audience, cares about the topic	"Your post is why I built this. No ask beyond telling me if it is wrong."
7	Replied to another maker's build-in-public thread on the same problem	Already curious about new tools here	"You were following that project. Here is a different take on it."
8	Ex-coworker who ran this exact process by hand	You know their real workflow	"Remember the Thursday report? This does it. Break it for me."
9	Someone who emailed you a question about this topic months ago	Already raised their hand once	"You asked me about this in March. I finally built it."
10	A maker in a builder community who traded feedback with you before	Owes you nothing, will reply anyway	"Swap? I will go through yours properly if you go through mine."

Ten rows, ten different sources, ten different sentences. That last one is worth doing deliberately: reciprocal feedback communities like Favors.dev exist so builders can trade real attention rather than upvotes, and one honest trade is worth more than fifty passive impressions.

What do you ask each of them for?

Never "check out my app". Ask for one specific action, bounded in time, with permission to be negative attached.

A message that works has four parts and fits in a phone screen: the thing they wrote, the one sentence of what you built, the small ask, and the invitation to criticise. For example:

"You posted last month about wanting to export these without a subscription. I built a free tool that does exactly that. Would you run one real file through it this week and tell me where it annoys you? Honest answers welcome, I would rather hear it now."

Three rules keep this from turning into spam:

1. One ask per person, never a broadcast. A BCC list is not ten messages, it is one message sent lazily, and everyone can tell.
2. Ask for a reaction, not a signup. "Tell me where it confused you" is a question a stranger can answer. "Create an account" is a chore.
3. Follow each venue's rules exactly. Hacker News is explicit that a Show HN should be something people can actually try, ideally without signup barriers, and that asking friends to upvote is not acceptable. Most communities have an equivalent line. Cross it once and you lose the venue permanently, which costs far more than ten users.

The other half of this is making the yes cheap to honour. If the first thing they see is a signup wall and an empty dashboard, a third of your yeses evaporate before they see anything. We wrote about that failure mode in detail in why nobody tries your app, and about the one sentence that has to do the work in how to write an app tagline.

How do you follow up without nagging?

Follow up exactly once, after two to three days, and make the follow-up carry new information rather than repeating the ask.

The version that gets replies is not "just bumping this". It is "I fixed the thing you would have hit first". Even if they never opened it, you have now told them the project is alive and that you act on feedback, which is the actual pitch.

Keep a two-column note of who you asked and what came back. Silence is data too: if seven of ten people who literally posted about this problem did not reply, the problem is your first sentence, not their inbox. After the single follow-up, stop. The person who ignored you twice may still show up in three months when they hit the problem again, and they will only do that if you did not annoy them.

What do you do with what they tell you?

Sort every piece of feedback into three buckets before you touch the code.

Blockers are the moments where someone could not proceed: the upload failed, the button did nothing, they did not understand what to do next. Fix these immediately and tell the person who reported it. "You said the import broke on big files, that is fixed" converts a tester into someone who is quietly rooting for you, and rooting-for-you people are where your next ten come from.

Preferences are "I would have done it differently". Write them down, act on none of them yet. At ten users a preference is one human's taste, and building for it will cost you a week.

Framing problems are the most valuable and the easiest to miss. If someone describes your project back to you and gets it wrong, the code is fine and your explanation is broken. Two people misdescribing it the same way is a rewrite of your homepage, not your app.

The uncomfortable outcome to plan for: sometimes ten people try it, nothing breaks, and nobody comes back. That is a real answer. It usually means the problem was annoying but not annoying enough to change a habit, and the right response is to change who you ask rather than to add features.

When do you go from ten to a hundred?

Go wider when two things are true. First, nobody in the last five people you asked hit a blocker. Second, at least a couple came back on their own, without a nudge. Until then, scaling the ask just means more people meeting the same wall.

Once you clear that bar, the ten-name method stops scaling and you switch to surfaces that keep working while you sleep: community threads where sharing is the point, a listing that stays up, and the reciprocal circuit. That is a different playbook, and it is the one in how to get your first 100 people to try your app. If you do not have testers lined up at all yet, finding beta testers with no audience covers the recruiting side, and where to post your app covers the venues.

One thing to do before you send message number one: give your ten somewhere to be sent. A link to a live page beats a screenshot every time, and if you want a permanent home that is not your own domain, you can list your app free on TryMy.App. Listings are free and reviewed by a human, and the only requirement is that people can actually try the thing without paying. That is the same standard your first ten will hold you to.

Frequently asked questions

How long should it take to get ten users?

Building the list takes about an hour. Sending ten personal messages takes another hour. Replies trickle in over a week, and a realistic outcome from ten well-sourced asks is three to five people who genuinely open it. So plan on two focused sittings and roughly two weeks of calendar time to get ten people through the door, which usually means writing more than ten messages.

Should I ask friends first?

Ask them, but do not count them. Friends will say it looks great because they like you, and that feedback is worthless for deciding what to build next. Their real value is as a rehearsal: if you cannot explain the project to a friend in one sentence without them squinting, your message to strangers is not ready. Keep friends in the list, mark them as friends, and weight what they say accordingly.

What if nobody replies?

Nobody replying is a finding, not a failure. Check the message before you blame the audience. The most common causes, in order: the opening line talks about you instead of the thing they wrote, the ask is too big, or the people you picked were not actually complaining about your problem, just adjacent to it. Rewrite the first sentence, pick ten fresh names from a different source, and send again. If two full rounds produce nothing, the problem is likely not painful enough for the people you chose, which is worth knowing before you spend another month building.

Do free users count?

For the first ten, yes. What you are buying at this stage is truth about whether the thing works and whether anyone bothers to come back, and a free user who returns twice tells you more than a paid user who was doing you a favour. Payment becomes the honest signal later, once the product does something a person would miss. Just be clear with yourself about which question you are answering, because a free user proving your onboarding works does not prove anyone will pay for it.