How to Get Your First 1,000 App Users: A Founder-Led Plan

It requires preserving the learning quality of your first 100 users while proving at least one acquisition motion can repeat without the founder personally recruiting every install. The milestone is not valuable if 900 people bounce before the core outcome.

Define a genuine user as a unique eligible person who installs, reaches a named activation event and is available in a source cohort. Bots, incentive exchanges, duplicate test accounts and staff devices do not count. Use the milestone to build distribution evidence, review trust and a diagnosable retention base.

• Activation: Choose the earliest event that demonstrates received value, not account creation. Validate it in analytics and backend where possible.
• Source: Tag every invite, community, content page, campaign and referral consistently. Preserve unattributed as a real category.
• Cohort: Read acquisition week, platform and source together. Counts remain small.
• Conversation: Maintain direct access to a sample from every channel. Scale should not erase explanation.

Decision rule: Count progress in activated users and retained cohorts, with installs shown only as the top of the funnel.

The number is a checkpoint, not a target, and chasing it directly is how teams end up with a thousand installs and no product. What the stage has to produce is a repeatable answer to three questions: which specific person the app is for, what they do in the first session that predicts they will return, and which source delivers more of them. A thousand users who cannot be described in one sentence teach you nothing, whereas two hundred who can will tell you what to build next. TestFlight is worth keeping in the loop past launch as a channel for the users willing to talk to you.

Define the activation event before you spend anything on acquisition. The first hundred users set the pattern this stage scales.

Use a diversified sequence: direct recruitment for the first 100–200, communities and partnerships for 200–500, searchable content and a launch for 500–800, then referrals or small paid tests for the remainder. The ranges are planning allocations, not guaranteed yields; audience fit and product category determine the actual mix.

Each channel should earn a role. Outreach gives conversations, communities give concentrated relevance, content gives compounding discovery, launches give a time-bound attention spike, referrals test advocacy and paid campaigns test scalability. Avoid making one viral event the plan.

• High-touch: Founder network, manual outreach, customer interviews and beta groups. Optimise insight per user.
• Borrowed audience: Niche communities, newsletters, creators and complementary partners. Earn trust and follow rules.
• Owned discovery: Problem pages, comparison pages, tools and demos that match search intent. Measure install handoff.
• Scalable tests: Referral and narrowly targeted paid acquisition after activation gates pass. Optimise downstream quality.

Decision rule: No channel receives the next 200-user allocation until its first cohort produces explainable activation and return behaviour.

Expect the mix to be lopsided rather than balanced, because at this scale one channel typically produces most of the value and the rest produce noise. Run three or four deliberately, give each a fixed budget of hours or money and a fixed window, then concentrate on whichever produced retained users rather than the most installs. The common error is spreading effort evenly across six channels so that none receives enough attention to work, then concluding that none of them work. Play's pre-registration and launch tools can concentrate demand into a single day, which is useful only if the product is ready to retain it.

Judge channels on week-two retention, not install count. Install sources behave very differently downstream.

Instrument activation, remove first-session blockers, prepare support and make store or beta access reliable before asking a larger audience to arrive. Distribution amplifies the current experience—including crashes, confusing permissions and broken deep links.

Run the journey on fresh devices and representative networks. Confirm analytics definitions, consent, crash reporting, attribution parameters and a safe way to contact support. The landing page, store listing and first screen should make the same promise in the same language.

• Access: Test TestFlight or Play opt-in, production availability, compatibility and deep links. Use a stranger’s device.
• Promise: Align ad, post, landing page, screenshots and onboarding. Message mismatch destroys conversion.
• Measurement: Validate source, install, first open, activation and retention events. Use a debug account then production-safe check.
• Response: Create support intake, incident owner and known-issue page or macro. Early users expect contact.

Decision rule: Do not begin a coordinated acquisition week until a fresh user can reach value and the team can identify where failures occur.

Fix the leaks before adding traffic, because acquisition at this stage is expensive in founder time and every wasted install is a user you cannot re-acquire. That means a working install path on both platforms, a store listing whose promise matches the first screen, an analytics event plan that can answer where people stopped, and a support route staffed by someone who replies within a day. A crash on a common device or an unclear first screen converts hard-won early attention into permanent loss. Play's testing requirements also gate new personal developer accounts, so build that lead time into the plan rather than discovering it at launch.

Rehearse the whole path on a clean device before any campaign. Onboarding is where most early acquisition is lost.

Turn one-to-one outreach into a documented message-and-introduction system while keeping every contact relevant and personal. The goal is not bulk cold messaging; it is to learn which problem, segment and proof consistently earn a response.

Build a list from opt-in waitlists, professional relationships, event participants, public problem discussions and introductions. Record why each person fits. Ask for one small action—try a beta flow or share with one appropriate colleague—and close the loop when their feedback ships.

• Segment: Choose one narrow user description for each outreach sprint. Avoid “anyone with a phone”.
• Message: Lead with the observed problem and why the person is relevant. Keep the app explanation to one sentence.
• Ask: Offer a direct safe link and a ten-minute task. Do not force a sales call.
• Learning: Tag objection, activation and returned feedback. Revise after twenty messages, not two.

Decision rule: Stop a message variant when it cannot earn relevant conversations; never compensate by sending it to more people.

Outreach scales through specificity, not volume. A hundred messages written for one clearly defined segment outperform a thousand generic ones, because the recipient can tell within a sentence whether you understood their problem. Keep a simple record of who you contacted, which segment they belonged to, what you said and what happened, so the message can be revised on evidence rather than instinct. Ask for a conversation rather than an install; the install follows from the conversation and the conversation is the part that changes the product. Show HN and similar forums reward a specific, honest description far more than a polished pitch.

Stop scaling a message that is not converting and rewrite it. Validation continues well past launch.

Contribute useful work before sharing the app, follow each community’s specific promotion rules and lead with a finding people can discuss without installing. Hacker News Show HN guidance and Product Hunt guidelines both reject coordinated vote solicitation.

Pick three communities where the target user already discusses the problem. Spend weeks answering, documenting and learning. Use sanctioned launch or self-promotion threads. Stay available after posting and publish limitations as openly as benefits.

• Fit: Choose communities by user problem, not audience size. Read rules and recent moderation precedent.
• Contribution: Answer questions and share original evidence before mentioning the product. Build a credible history.
• Post: Tell the problem, method, result and what feedback you need. Disclose affiliation immediately.
• Follow-through: Reply, fix issues and return with the outcome. Do not disappear after traffic peaks.

Decision rule: If the post provides no value to a reader who never installs, it is an advertisement and should use the community’s advertising route.

Earn standing before asking for anything, because communities are durable assets you can spend exactly once if you get it wrong. Read the rules, participate for weeks on other people's questions, and post about your product only where that is explicitly welcome and in the format the community expects. Disclose that it is yours every time. The return is slower than a paid campaign and considerably more durable — a community that trusts you keeps sending users long after a campaign stops. Product Hunt's community guidelines are a reasonable model for what most communities expect of a founder posting their own work.

One badly received self-promotion can close a channel permanently. Community-led distribution covers the longer game.

Publish pages that solve the exact problem immediately before someone needs the app: guides, templates, calculators, comparisons and demonstrable workflows. A generic company blog rarely creates early distribution because it matches no urgent query or shareable task.

Interview language supplies topics. Choose one narrow search and community wedge, create the best answer and make the app the natural next action rather than a gate. Instrument page, store click, install or web sign-up and activation while respecting consent and attribution limits.

• Problem guide: Answer a recurring high-intent question with current primary sources. Give the useful answer before the CTA.
• Tool or template: Let users complete part of the job immediately. Make output genuinely reusable.
• Comparison: Help users choose among approaches, including when the app is not fit. Earn trust through boundaries.
• Case evidence: Show method, baseline, intervention and result without inventing performance. Separate observation and inference.

Decision rule: Choose content whose satisfied reader is disproportionately likely to need the product’s activation event.

Write for the problem people already search for, not for the product you built, because nobody is looking for an app whose name they have never heard. A guide that solves the problem completely — including without your app — earns the credibility that makes the install a reasonable next step. Expect a long lag: content published now produces traffic in months, which is why it should start early and run alongside faster channels rather than instead of them. Measure assisted installs rather than last-click, or content will look worthless. Apple's promotional resources cover what may be claimed about App Store placement in your own marketing.

One genuinely useful asset beats ten thin ones. App SEO explains how web traffic becomes installs.

Concentrate already-earned attention into a day while protecting onboarding, support and measurement; do not expect the launch platform to create an audience from zero. A launch is a coordination event across owned list, communities that permit it, partners, store assets and founder presence.

Prepare a single canonical page, platform-specific store links, tested analytics and a support rota. Brief existing supporters to try and share honestly, never to coordinate votes. Schedule demonstrations and founder replies across the day. Keep the product stable and document traffic incidents.

• Before: Seed beta users, testimonials with permission, screenshots, FAQs and known limitations. Test every destination.
• Message: State who it is for, the job, proof and one next action. Keep platform claims consistent.
• Live: Respond to questions and failures, watch activation and pause promotion if the path breaks. Support is part of launch.
• After: Follow up, publish learning and cohort users by source. Do not judge on day-one installs alone.

Decision rule: Launch only after you can reliably turn attention into activation and answer users while the conversation is live.

Treat a launch as a concentration of demand you already have, not a source of new demand. The teams whose launch days work spend the preceding weeks building a list of people who agreed in advance to show up, then ask them on the day. Without that, a launch is a few hours of traffic from strangers with no reason to care. Plan the day after as carefully as the day itself: the follow-up to everyone who engaged is where the retained users come from, and it is the step most often skipped in the exhaustion afterwards. Play's custom store listings let you match the landing experience to the campaign that sent the user.

A launch will not rescue a product that does not retain. Soft launch is the lower-risk alternative.

Add referrals after users repeatedly reach value and can name who else has the same need, not merely after the install counter rises. A reward cannot manufacture advocacy for a product people do not yet retain.

Start with a natural share object, collaboration invite or useful output before adding economic incentives. Ask after the value moment. Attribute server-side, define a qualified new user and model reward cost, fraud and incrementality. Hold out an eligible cohort where feasible.

• Trigger: Place the ask after completion, progress or delight. Avoid interrupting onboarding.
• Recipient value: Explain why the invited person benefits immediately. Do not make them a means to a reward.
• Qualification: Use an activated or value-bearing event and clear rules. Prevent self-referral and duplicates.
• Measurement: Track invite, recipient activation, retained value, reward cost and abuse. Estimate organic baseline.

Decision rule: A referral loop is ready when invited recipients activate at healthy rates and the referrer’s motivation remains understandable without the reward.

Add the loop only once the product has something worth sharing, because a referral programme on an app people do not love simply exports indifference. The precondition is a retention curve that flattens rather than decays to nothing, and a moment in the product where sharing is genuinely useful to the recipient. Trigger at that moment rather than at launch or on a timer. Reward the recipient at least as well as the referrer — one-sided programmes read as the user doing your marketing for a discount. The in-app review API has the same timing principle: ask after value, never before.

Instrument the loop before switching it on. Referral fraud controls belong in the design, not bolted on later.

Test paid acquisition when activation is stable, a retention plateau exists, the target segment is specific and measurement can distinguish source quality. The first campaign is a diagnostic purchase of evidence, not a scale announcement.

Choose one platform, one market and one primary creative hypothesis. Optimise initially toward the deepest event that occurs often enough for delivery to learn, while reading activated and retained cohorts outside the ad dashboard. Cap spend at an amount the team can afford to learn from.

• Readiness: Three comparable cohorts show stable activation and some voluntary return. Fix the funnel first.
• Design: One channel, segment, geography and meaningful creative contrast. Avoid fragmented budgets.
• Economics: Set maximum cost per activated or retained user from conservative value. CPI alone is insufficient.
• Decision: Write spend cap, observation window and scale, iterate or stop gates. Reconcile platform and backend.

Decision rule: Do not increase budget until paid users reach value and return within an acceptable cost range for at least three comparable cohorts.

Delay paid acquisition until you can tell a good install from a bad one, because paid traffic buys volume at whatever quality your funnel currently produces. The readiness test is whether you can name the activation event, measure retention by source and state what a retained user is worth. Without those, a campaign teaches you only your cost per install, which is the least useful number available. Start with a budget you can afford to write off entirely, treat the first spend as measurement rather than growth, and expect learning-phase costs well above eventual steady state. TestFlight cohorts remain a cheaper source of qualitative signal alongside any paid test.

Judge the test on retained users per pound, not installs per pound. ROAS and CAC set the framework for that decision.

Use four three-week phases: instrument and recruit, prove community fit, compound content and launch, then validate referrals or paid scale. The target is a planning scaffold; weekly evidence should change channel allocation.

Keep the product stable enough to interpret cohorts while shipping corrections to clear failure points. Every Friday review activated users, week-two returners, source, conversations, severe issues and next allocation. Reserve capacity for support and reliability.

• Weeks 1–3: Recruit the next 100–200 personally, validate activation and repair the first-session path. Prepare store trust assets.
• Weeks 4–6: Work deeply in three communities and two partner audiences. Publish the first high-intent asset.
• Weeks 7–9: Run the launch moment and expand the content cluster from real questions. Read source cohorts.
• Weeks 10–12: Test a referral loop and one capped paid campaign if gates pass. Choose the repeatable engine.

Decision rule: Graduate when one channel beyond personal outreach produces three cohorts with stable activation, retention and an affordable acquisition cost.

Sequence the twelve weeks so each phase produces the input the next one needs, rather than running everything at once. Early weeks are for high-touch outreach and the conversations that sharpen the positioning; middle weeks apply that language to communities and content; later weeks concentrate demand into a launch moment and test whether anything scales. Hold a fixed weekly review with the same three numbers — new users, activation rate and week-two retention — and be willing to abandon the plan when the data disagrees with it. A plan followed past its expiry is worse than no plan. Play's launch tooling should be configured well before the week you intend to use it.

Write down what you expect each phase to produce before it starts. The stage after this one depends on knowing which channel actually worked.