Your first 10 users, by hand

Makers say the same two sentences about their first app: “I love building” and “I hate launching”. The second one usually means they posted a link somewhere, got three downloads, and concluded the app was the problem. It was not. The launch was. New apps are not found; they are delivered, by hand, to ten people. Here is how that month goes.

1. Launch day is silence, and that is normal

A post on a forum, a link on social media, a listing in the store: for an app nobody has heard of, each of these produces almost nothing, and the nothing is not a verdict. Most launches are received with silence. One maker who tracked it took forty days to reach a hundred users, most of them one conversation at a time.

Paul Graham’s essay “Do Things That Don’t Scale” is the oldest advice here and still the best: the founders of nearly every company you have heard of recruited their first users manually, one by one, in ways that could never have scaled, and that was the point. Your first ten do not come from a launch. They come from you.

2. Go where the question is already being asked

Somewhere, people are already asking for what you built. A parents’ group asking how the club shares fixtures. A forum thread asking for a simple way to take pre-orders. A community where small landlords complain about tracking inspections. Find three of those places and read them for a week before you type anything.

Then answer the questions. Properly, in full, with no link. When someone’s problem is exactly the one your app fixes, say so in one line and offer to set it up for them. The rule every community enforces, written or not: be a person who happens to have made something, not a product that happens to have an account. Roughly one message in ten can mention your app, and never the same link in several places on the same day.

3. Install it for them, literally

Your first ten users should not find the app in a store. You should put it on their phones. On Android, send the test link and watch them install it. On iPhone, add them to TestFlight (Apple’s app for testing before release) and walk them through the two taps. Sit with them, in person or on a call, while they use it for the first time.

This has a second purpose. Google requires a new developer account to run a closed test with 12 people for 14 days before the app can go public. Your first ten users are those testers. Recruit a few more than twelve, because the fourteen days restart if the count drops.

4. Ask for the complaint, not the compliment

Everyone you install it for will say it looks great. Ignore that and ask one question: “What did you expect to happen when you tapped that?” Then watch. The screen where they hesitate is the next thing you fix. The feature they ask for is a maybe. The place they got lost is a certainty.

Write each one down with their name next to it. Ten people, ten notes. That list is worth more than any amount of analytics, because you can call each of them back when it is fixed, and they will tell the next person.

5. Ten, then look at what changed

When you have ten people who open the app without being reminded, stop recruiting for a week and read the notes. Fix the two things that stopped the most people. Then go back to the same three places, with the fixes, and get the next ten.

If you are still before the first user, the cheapest first step is the design itself: put it on the phone of one person who has the problem, before any build, and ask the question in step 4. The App Builder preview is enough for that conversation.