Your First 100 App Users: Growth Tactics That Cost Nothing

The first 100 users are a research problem; the next ten thousand are a distribution problem, and almost every mistake founders make at this stage comes from treating the two as the same job at different volumes. They are not. The inputs are different, the tools are different, and the definition of success is different.

At ten thousand installs you are optimising a machine that already works. You know which creative wins, which geography is cheapest, which onboarding step drops the most people. You have enough events for the numbers to mean something, and enough spend for a channel algorithm to find a pattern. Every decision is a tuning decision.

At 100 installs you are still deciding whether the machine should exist. You do not have statistics — you have anecdotes, and you need enough of them to see a shape. If 40 of your first 100 users open the app again on day two, that is not a 40% day-one retention rate you can plan around. It is 40 people. Change one screen and the number can swing ten points on noise alone. Any A/B test you run at this volume will tell you a confident story about nothing, which is worse than having no story at all.

The second reason this stage is different is that none of the automated systems you will eventually rely on can help you yet. Algorithmic ad channels need a steady stream of the same conversion event before their models stabilise; feeding them a handful of installs a week produces expensive randomness. Store discovery is no kinder. Google's own Play app discovery and ranking documentation describes ratings, reviews and engagement as inputs into how apps are surfaced — all of which are signals you simply do not have a hundred users into your life. You cannot rank your way to your first users, because ranking is downstream of having users.

So what are the first 100 actually for? Four things, in order of value. They give you conversations — the raw material for every product decision you will make in the next six months. They give you device and network coverage that no emulator reproduces, which is where the crashes hide. They give you your first ratings and written reviews, which are the assets that make every later channel convert better. And on Android specifically, they satisfy a hard gate: a personal Play Console account created after 13 November 2023 needs 12 testers opted in to a closed test continuously for 14 days before it can apply for production access, a rule we cover in detail in our guide to Google Play closed testing.

Across the 300+ apps we have managed since 2013, the teams that struggle hardest at scale are almost always the ones that skipped this stage — they bought their way to 50,000 installs before anyone had spoken to a user, and then spent a year trying to work out why retention was flat. The teams that move fastest treat the first 100 users as fieldwork, and they finish that fieldwork before they open an ad account. If you have not yet shipped, our pre-launch app marketing guide covers what to set up before this stage begins.

One more framing that helps: at this stage your job is not to be found. It is to find people, one at a time, and to be worth their attention when you do. Everything below follows from that.

Five zero-budget channels reliably produce real early users: the beta distribution rails both stores already give you, niche communities, founder-led posting on the platforms where your users already argue about your problem, one-to-one direct outreach, and the editorial featuring route almost nobody bothers with. Everything else at this stage is either paid in disguise or a waste of a week.

1. The store beta rails. These are free, they are official, and they are the fastest way to get a build into strangers' hands — but the two stores are not symmetrical, and the asymmetry is where first-time Android developers lose a fortnight. On iOS, Apple's TestFlight documentation sets the ceiling at 100 internal testers and 10,000 external testers, and a public link can be capped anywhere between 1 and 10,000 people. Builds stay testable for up to 90 days, and the first build you send to an external group goes to Beta App Review. Apple publishes no turnaround time for that review, so build slack into the schedule for your first external build rather than pinning a launch date to it.

On Android the free rail exists, but it is not the one most launch guides name. Play Console Help lists internal testing for up to 100 testers, closed testing lists holding up to 2,000 users each, and open testing that is unlimited by default or capped at a floor of 1,000 — but Google's testing requirements make open testing available only after you gain production access, and the 12-testers-for-14-days rule has to be satisfied by a closed test. For a personal developer account created after 13 November 2023 — which is most people reading this — the pre-production rail is therefore closed testing, run through an email list or a Google Group, and the beta you use to find your first users is the same test that unlocks production. Plan for that, and treat open testing as something that arrives afterwards rather than something you can share on day one.

Either way you finish with a shareable opt-in link — a public TestFlight link on iOS, a closed-testing opt-in URL on Android — which means every other tactic in this article has somewhere to send people before you are live in production.

2. Editorial nomination. This is the single most underused free channel on either store. Apple runs a featuring nomination form through App Store Connect for apps, games, in-app content and developer stories; it asks for a minimum of two weeks notice and recommends submitting up to three months in advance for wider consideration. It costs nothing but an hour of writing. Google's side is not equivalent, and it is worth being precise about that rather than repeating the folklore. Play has no public, app-wide nomination form. What Google publishes is a featuring guide built on four pillars of app quality — core value, user experience, technical quality, and privacy and security — which is what its editorial team is assessing; the only submission form on that page is a promotional one for premium titles, judged on quality, historical performance and the depth of the proposed discount. So on Play the work is the nomination: meet the four pillars, keep technical quality high, and you become eligible for editorial consideration rather than applying for it. Apple's form is not a lottery ticket you should plan a launch around either, but the expected value of one hour of writing is unusually high, and in our portfolio the developers who submit a nomination are a small minority.

3. Niche communities. Subreddits, Discord servers, Slack groups, WhatsApp and Telegram groups, forums, and the comment sections of the newsletters your users read. This is where the first 100 realistically come from for most apps, and it is the channel with the most ways to get it wrong — the whole of the next section is about doing it without being banned.

4. Founder-led posting. Not a brand account. You, posting under your own name, about the problem rather than the product. Building in public — sharing what broke, what you measured, what you decided — works because it gives people a reason to follow you before they have a reason to install anything. It compounds slowly and it is free.

5. Direct outreach. One person, one message, written by hand. Covered in full below, because it is the channel most founders skip and the one that most reliably works.

Earn standing before you ask for attention — the only method that reliably works is to be a genuinely useful member of a community for weeks before your app is ever mentioned, and then to mention it once, in the format that community allows. There is no shortcut, and the shortcuts are exactly what moderators are trained to spot.

Start by recognising where the enforceable rules actually live. Platform-level policies cover spam and vote manipulation, but the rules that get you removed are written by the individual community: the subreddit sidebar, the Discord server's rules channel, the pinned post at the top of the forum. Read them before you post, not after. Many communities have exactly the outlet you need — a weekly self-promotion thread, a "show off your project" megathread, a dedicated flair — and using the sanctioned outlet costs you nothing while ignoring it costs you the community permanently.

Hacker News publishes its expectations openly, and they are a good template for how to think about every other community. The Show HN guidelines require that the project be something you made personally that others can actually try, that you be around to discuss it, and that you remove barriers such as sign-ups so people can use it. Landing pages, fundraisers, newsletters and blog posts do not qualify. The guidelines are also blunt about coordination: "Please don't ask friends to upvote or comment. That's not ok on HN." Product Hunt's community guidelines take the same position from the other direction: mass messaging users, asking for upvotes, using bots and incentivising upvotes are all listed as unacceptable, and attempting to game the system can mean the post is removed and the account loses contribution access.

The practical sequence we recommend to early teams in our portfolio is boring and it works:

1. Pick three communities, not thirty. Depth beats breadth. You want to be a recognised name in three places, not an unfamiliar link in thirty.
2. Spend two to four weeks contributing only. Answer questions in your domain. Post something useful that has nothing to do with your app. Build a comment history a moderator can look at.
3. Lead with the finding, not the product. "I analysed 400 GST invoices and here is why the tax field breaks" is a post. "Check out my invoicing app" is a removal. The app belongs in one line at the end, or in a comment when someone asks.
4. Answer every reply for 48 hours. The comments are the product of the post. A thread where the author responds thoughtfully to twelve people converts far better than one with 200 upvotes and silence.
5. Never post the same thing in five communities on the same day. Cross-posting patterns are the easiest spam signal there is, and moderators of related communities talk to each other.

Be honest with yourself about the intent test. If the only reason you are in the community is to extract installs, that will be visible in your writing within two sentences, and people will treat you accordingly. The founders who do well here are usually the ones who were already members before they had an app — they built the thing because the community complained about the problem for two years.

Finally, weigh the cost of getting this wrong. A ban from the one subreddit where your users congregate is not a slap on the wrist; for a niche B2B or vertical app it can remove your single best organic channel for the life of the product. There is no appeals process worth relying on. Treat each community as a one-shot resource and spend it carefully.

Realistically, tens to low hundreds of installs — not thousands — and the durable value is almost never the install count. Anyone promising you a five-figure launch day from a free community post is describing an outlier, usually one with an existing audience behind it that they are not mentioning.

Take Product Hunt first, because it is the launch most founders fixate on. Its help centre states that the homepage is ranked on points and that one upvote does not always equal one point — the conversion depends on factors including featured status, overall community engagement and the authenticity of incoming votes, and Product Hunt deliberately declines to disclose all of them so the ranking is harder to game. The daily leaderboard runs on those same points. So the mechanism you are entering is not "collect the most votes"; it is "generate the most genuine engagement", which is a much harder thing to manufacture. Soliciting or incentivising upvotes fails twice over: the community guidelines forbid it, and the points model discounts votes it reads as inauthentic anyway.

Then there is an audience mismatch that nobody warns first-time mobile founders about. Product Hunt's core audience browses on desktop, evaluates web products, and converts by clicking through to a website. For a mobile app, that traffic has to survive an extra two steps — landing page, then store page, then install — and each step drops most of the people who were merely curious. A launch that produces a few thousand page views commonly produces a small fraction of that in store visits, and a fraction of that again in installs. The funnel is real and it is brutal.

So why do it at all? Because the by-products outlast the traffic:

• Written feedback from strangers with no social obligation to you. This is the most valuable thing you will get all quarter, and it only arrives in public threads.
• Your first ratings and reviews. Community-sourced users write longer, more specific reviews than paid users, and those reviews improve conversion for everyone who arrives afterwards.
• A handful of power users. Out of 200 installs you might find five people who use the app daily and reply to every email. They are your product council for the next year.
• Durable links and search surface. The thread itself keeps ranking, and it is often the first thing a prospective user finds when they search your app's name.
• A reason to talk to people. Every commenter is someone you can message directly, which feeds the outreach loop described below.

Two rules for sequencing. First, do not spend your Product Hunt launch on a build that is not ready. A relaunch is possible — Product Hunt asks makers to wait around six months between posts for the same product and to have shipped a significant update, with an earlier attempt needing a request that explains what changed — but you only get one first impression, and one made on a crashing beta is expensive to undo. Second, do not schedule all your community posts in one week. Spread them, so each one gives you a fresh batch of users to interview while you are still shipping fixes from the last batch. A launch is a sampling event, not a growth channel.

Talk to every single one of them — personally, by name, within a day or two of install — and turn what you hear into a shipped change fast enough that the person who reported it notices. At 100 users this is not a support burden; it is the entire growth strategy, and it is the only period of your product's life when it is possible.

The mechanics are simple and most teams still skip them. Message each new tester individually. Not a broadcast, not an in-app survey — a message that references something specific about them or how they found you. Ask one question, not five. "What were you trying to do when you opened it?" produces more usable information than any rating scale. Offer a 15-minute call to the ones who reply with substance; across the early-stage teams in our portfolio roughly one in five of those repliers takes it, and those calls are where the real problems surface, because people will say out loud what they will never type into a feedback form.

Instrument exactly one thing before you start: the activation event. Not installs, not sessions — the single action that means a user has understood what the app is for. For an invoicing app it might be the first invoice sent; for a fitness app, the first completed workout; for a trading app, the first watchlist created. Then track the gap between install and that event for every user by name. Our guide to the activation aha moment goes deeper on choosing that event, but the rule at this stage is that if you cannot name the moment, you cannot fix the drop-off before it.

Ratings are the second half of the loop, and they have rules worth knowing before you start asking. On Android, the Play in-app review API is subject to a time-bound quota that Google deliberately does not publish and can change without notice, which is why the documentation tells you not to put a button behind it — a user who has hit their quota sees nothing, and you have shipped a dead control. The same guidance prohibits asking users a qualifying question first, such as whether they like the app or whether they would rate it five stars, and prohibits modifying or overlaying the card. On iOS, the constraint is stricter in a different way: incentivising or filtering reviews is a Developer Program violation, not just a design mistake. Ask at the right moment, ask once, and never pay for the answer. The moment that works is the second or third time a user completes the activation event successfully, never on first launch and never straight after a crash.

Run the loop on a weekly cadence and make it visible:

1. Monday: list every user who installed last week and every user who stopped opening the app. Message both groups with different questions.
2. Midweek: ship the smallest change that addresses the most-repeated complaint. Small and shipped beats correct and queued.
3. Friday: reply to the specific people who raised it, telling them it is fixed and in which build.

That last step is the one that converts a tester into an advocate. Someone who watches their complaint turn into a release note within a week will tell other people about your app without being asked, and will keep opening it long after the novelty has worn off. Across our portfolio, this reply-back habit is the clearest behavioural difference between early teams that build a retained base and early teams that accumulate installs and lose them.

Because it is the only channel that delivers the install and the conversation in the same message, and at 100 users the conversation is worth more than the install. Manual outreach does not scale — that is the feature, not the flaw. It forces you to understand each user before you have the option of ignoring them in aggregate.

Start with the arithmetic, because it makes the work feel finite and because the arithmetic is where most zero-budget advice quietly cheats. Twenty genuinely personal messages a day, five days a week, is roughly 400 messages a month — an hour and a half of work daily. On cold outreach to well-chosen people, the early-stage teams in our portfolio see a reply rate in the teens, so call it 50 to 60 replies, of whom perhaps a third to a half install when the ask is small and the fit is obvious. That is 20 to 30 users a month from outreach alone, or 40 to 60 across a six to eight week push. Outreach is not the whole hundred and nobody should tell you it is; it is the half of the hundred that depends on nothing outside your control — no algorithm, no moderator, no budget approval — while two or three well-earned community posts over the same period supply the rest.

Where do the names come from? In order of quality:

• People who publicly described the problem. Anyone who complained about the thing your app fixes, in a forum thread, a review of a competitor, or a post. They have already self-identified.
• Reviewers of competing apps. One and two-star reviews of the incumbent are a specification document written in your users' own words — the exact phrasing for what is broken and who it breaks for. Treat them as research, not as a lead list: store reviewers are pseudonymous, there is no contact route, and mining store profiles to send unsolicited pitches is a spam and data-protection problem before it is anything else. Take the language, then go and find those people somewhere they can actually be contacted.
• Your own second-degree network. Not your friends — their colleagues. Ask five people for two introductions each rather than asking 50 people for a favour.
• Everyone who touched your community posts. Commenters, repliers, people who asked a follow-up question. They already know who you are.

The message itself follows four rules. Make the first line about them, and make it specific enough that it could not have been sent to anyone else. State in one sentence what the app does and who it is not for — disqualifying people builds more trust than any claim. Make a single small ask, usually a public TestFlight link on iOS or a closed-testing opt-in URL on Android rather than a call. And close a loop later: if they said no, thank them; if they said yes, follow up once when the thing they mentioned is fixed. Volume without personalisation is spam with extra steps, and it will burn the same lists you need in six months.

The honest end of this: manual outreach stops being the right tool the moment the message can no longer be personal. When you are copying and pasting, you have already crossed the line, and the next channel — paid, or content, or referral — should be taking over. Across the 300+ apps we have managed since 2013, the founders who did this stage by hand were consistently the ones whose paid campaigns worked later, because they knew exactly which sentence made someone install.

Stop when three gates are clear: your activation rate is stable across your last three weekly cohorts, your retention curve flattens instead of falling to zero, and you can describe the person you want to buy in one sentence. Until all three are true, paid installs buy you noise at full price, and the noise looks enough like progress to keep you spending.

Gate one — activation is stable. Take the single activation event you instrumented earlier and look at the rate across your last three weekly cohorts. If it swings from 20% to 55% to 30%, you do not have a product behaviour yet, you have variance. When the same share of new users reaches the moment week after week without you personally onboarding them, the funnel is real and paid traffic will enter something that works.

Gate two — the curve flattens. Retention curves that go to zero mean the app has no repeat use case; pouring installs into that hole is the most expensive mistake in mobile. What you are looking for is a curve that drops steeply and then levels off, however low the plateau sits, because that plateau is the population who genuinely want the app. Judge the shape against your own earlier cohorts rather than against a published category average — those benchmarks are blended across app types, business models and sample sizes that have nothing to do with yours, and at this volume they will confirm whichever story you already preferred. What matters is whether a plateau exists at all, and whether it is rising, flat or falling cohort over cohort.

Gate three — you can name the buyer. "Freelance designers in Indian metros who invoice more than five clients a month" is a targetable sentence. "Anyone who needs to send invoices" is not. Every paid channel needs an audience definition, a geography and a creative angle, and all three come out of the 100 conversations you just had. If you cannot write the sentence, you did not finish the fieldwork.

There are two order-of-operations details that trip teams up. On Android, clear the production-access gate before you plan any spend: a personal Play Console account opened after 13 November 2023 needs 12 testers opted in to a closed test continuously for 14 days, and no amount of budget shortens that clock. On both platforms, fix store-listing conversion before you buy traffic — paying to send people to a listing that converts poorly means paying the poor conversion rate on every single install, forever. Screenshots and the first impression frame are the cheapest thing to fix and the most expensive thing to ignore.

When all three gates are clear, the next rung is a structured push rather than a bigger version of what you have been doing by hand. Our guide to getting your first 10,000 installs covers that stage — paid channels, CPI, creative volume — and our breakdown of a realistic year-one app marketing budget covers what that costs in practice. If you would rather have the first paid campaigns run by a team that has done it before, our user acquisition service exists for exactly that transition.

Counts and named people, not rates and dashboards — at this stage every percentage you compute has an error bar wide enough to justify any decision you already wanted to make. The discipline is to measure a small number of things honestly and refuse to over-read the rest.

Five things are worth tracking before you have volume:

• Install-to-activation, as a count. "31 of the last 50 installs sent an invoice" is a fact. "62% activation" invites a comparison to benchmarks that do not apply to a sample of 50.
• Week-two returners. The number of people who opened the app in week two without you messaging them. This is the least gameable early metric there is, and it is the closest thing to a north star before you have scale.
• Crash-free sessions and device coverage. Your first 100 users are also your compatibility matrix. One crash on a common mid-range Android device can quietly destroy a whole cohort, and you will read it as disinterest.
• Time to first value. Measured in seconds from first open to the activation event. Watch the distribution, not the average — the users who take four minutes are telling you where the confusion sits.
• Ratings and written reviews. Both a metric and an asset. Google's Play documentation names ratings, reviews and engagement among the signals that inform how apps are surfaced, so early review volume compounds into discovery later.

Equally important is the list of things not to measure yet. Do not compute cost per install when you have not spent anything, and do not compute lifetime value from a handful of transactions. Do not run store-listing experiments at this traffic level — controlled listing tests need real visitor volume to reach a conclusion, and running one on a trickle produces a result that reverses the next time you look. Do not build a dashboard. A spreadsheet with one row per user, a column for how they found you, a column for whether they activated, and a column for what they said is more useful than any analytics suite at n equals 100, and it forces you to look at people rather than aggregates.

Cohort by source, even at tiny numbers. Twelve users from one subreddit behaving completely differently from twelve users from your own network is a signal worth acting on, and it will not show up in a blended number. In our portfolio, source-level differences at this stage frequently predict which paid channel works six months later — the community that produced your stickiest early users usually points at the audience your ads should target.

Finally, keep a qualitative log with the same rigour you apply to the quantitative one. Tag every piece of feedback with a short theme, count the themes weekly, and let the count drive the roadmap. When the same complaint appears in eight of twelve conversations, that is a stronger signal than any statistically underpowered funnel chart, and it is available to you months before your event data could ever prove it.

The whole of this stage comes down to one question you should be able to answer every Friday: how many people used the app this week because they wanted to, and do you know why? When the answer is a number you trust and a reason you can state in a sentence, you have finished the first 100 and earned the right to spend money.