Founders researching how to get first app users should start with direct invitations to a narrowly defined audience, then use feedback and repeat usage to guide a wider launch. This article sets out a low-cost approach to finding the first 100 users, covering outreach, community participation, onboarding and referrals for a new app.
Key takeaways
- Define the first audience by a specific problem and recruit people who already spend time or money addressing it.
- Begin with personal introductions and individual outreach, using early conversations to test the proposition before promoting the app more widely.
- Count users who complete a meaningful task, rather than treating every registration or download as evidence of demand.
- Participate in relevant communities before sharing a launch link, and make each contribution useful without requiring an app registration.
- Expand acquisition only when onboarding works and early users return at a frequency that fits the problem being solved.
What is early app user acquisition?
Early app user acquisition is the process of finding people with a relevant need, persuading them to try an app and helping them experience its main benefit. For a new product, the first 100 users are a learning group rather than proof of a repeatable business model.
A download, registration and active user represent different stages. A booking app might count someone who completes a booking as activated; a business tool might require a user to create and share their first report. Define that event before launch so acquisition has a consistent measure.
The target also depends on the business. A consumer app may need many individuals to reveal useful patterns. A business product can learn substantially from a smaller group of organisations, particularly where several people share the buying decision.
Choose a narrow audience before choosing channels
“Busy professionals” is too broad to guide recruitment. “Independent physiotherapists who manage appointment changes through email” gives a founder a clearer problem, likely meeting places and a reason to start a conversation. The first audience should be reachable as well as relevant.
Identify the existing alternative. Prospective users may rely on spreadsheets, messaging groups, paper records or a competing app. Understanding that behaviour helps explain why switching would be worthwhile and what the MVP must support.
Before outreach begins, write down:
- The person who experiences the problem and, if different, the person who pays.
- The situation that makes the problem urgent enough to address.
- The first useful outcome the app can deliver.
- The places where those people already discuss their work or interests.
A simple landing page should reflect these choices. State who the app serves, what it helps them do and whether access is immediate or invitation-only. Avoid presenting an unfinished feature as available. A short, accurate demonstration is more useful than a long list of planned capabilities.
Recruitment also exposes scope problems. If every prospect asks for a different product, the audience may be too broad. Adding every requested feature usually postpones the decision about whom the app actually serves.
How to get first app users through direct outreach
Start with people who can introduce relevant prospects, rather than asking every acquaintance to register. Friends can provide encouragement, but encouragement is weak evidence of demand. An introduction to someone who regularly experiences the problem is more valuable.
Keep individual messages brief and specific. Explain why the person appears relevant, describe the problem being investigated and ask whether they would consider trying an early version. Make the time commitment clear. Do not imply a personal connection that does not exist or send repeated unwanted follow-ups.
For example, a founder building a tool for freelance project handovers could approach freelancers who have publicly discussed client administration. The message should refer to that problem, not praise their profile before delivering a generic pitch.
Use early sessions to observe behaviour:
- Ask how the person currently completes the task and what causes difficulty.
- Give them access and describe an outcome to attempt, without explaining every control.
- Watch where they hesitate, misunderstand labels or abandon the task.
- Ask what would make the app worth using again, then arrange a relevant follow-up.
A small initial group, perhaps around ten relevant testers as a planning target, can reveal obvious obstacles before a broader release. Keep those who needed extensive guidance separate from those who completed the task independently. Both groups offer useful feedback, but they show different levels of product readiness.
Find users in communities without posting spam
Niche communities often offer better early access than large launch platforms. Relevant professional associations, specialist forums, LinkedIn groups and local business networks bring together people with shared needs. Choose places where the intended users participate, rather than places populated mainly by other founders.
Read the rules before posting. Some groups allow product feedback requests only in designated threads; others prohibit promotion altogether. Answer existing questions, share useful observations and ask moderators before proposing a testing invitation.
Building in public can support this work when updates concern the user's problem. A short account of an onboarding change, including what testers found confusing, gives prospects something concrete to assess. Repeated announcements about features rarely provide the same reason to engage.
Directory listings and launch sites can supplement direct recruitment. Select those used by the intended audience, and send visitors to a page that matches the listing's promise. Record the source through a simple campaign link or an optional sign-up question.
For mobile apps, allow for store review and make the route to installation clear. Browser-based products should be tested on the devices prospects actually use. A launch post loses value if its link leads to unavailable access or an unsuitable screen.
The first users are most useful when their behaviour can challenge the product's assumptions. A large audience with little reason to return offers less guidance than a small group completing real work.
Fix onboarding before increasing acquisition
Acquisition and product development are closely connected at this stage. If interested people register but never complete the main task, more promotion may simply repeat the same failure. Review the route from invitation to first useful result before adding another channel.
Remove questions that are not needed immediately. Explain unfamiliar terminology, provide a sensible starting point and make errors recoverable. Sample content can demonstrate a workflow, but it should be clearly labelled and easy to replace with the user's own information.
Track a small set of events: registration, completion of the core task and a meaningful return visit. Add acquisition source where practical. A basic spreadsheet alongside product analytics may be sufficient initially; the aim is to understand what happened, not build an elaborate reporting system.
Interpret return behaviour against the task's natural frequency. A weekly planning tool should not be judged by daily usage. A service used for an occasional event needs different evidence, such as successful completion or a recommendation to another suitable customer.
Contact users who stop before activation and ask where they became stuck. For those who finish once but do not return, investigate whether the need recurred, whether the result was useful and whether another approach remained easier. Avoid interpreting every departure as a request for more features.
Build a manageable plan towards 100 users
A staged plan keeps limited founder time focused. A rough four-to-twelve-week working window can help organise recruitment and product fixes, but it is a planning allowance, not a forecast. Specialist business products and infrequent-use services may need longer.
- Prepare: define the audience, activation event, landing page and source tracking.
- Recruit a small testing group: use introductions and individual invitations, then resolve repeated obstacles.
- Repeat the best route: maintain outreach and contribute to a small number of relevant communities.
- Ask satisfied users for introductions: make the intended recipient and likely benefit clear.
- Review the evidence: compare activation and return behaviour by source before expanding activity.
Referral requests work best after someone has received value. Ask whether they know a colleague with the same problem, and offer a short explanation they can forward. Avoid contact-list uploads or incentives that reward registrations regardless of suitability.
Paid advertising can wait until the proposition and onboarding have some supporting evidence. A small, capped experiment may answer a specific question, but buying traffic to compensate for weak retention is unlikely to resolve the underlying issue. Low-cost recruitment still has a cost in founder time, so record the effort involved as well as cash expenditure.
Frequently asked questions
How can an app get users without paid advertising?
Start with relevant introductions, individual outreach and participation in communities where potential users already discuss the problem. Offer a clear reason to try the app and help early users complete its main task. Referrals and selected directory listings can extend that work once the initial experience is reliable.
Should the first app users get free access?
Free access can reduce the commitment required for early testing, but it does not establish willingness to pay. Explain any trial limits and future charging intentions clearly. For a paid product, conversations about price or a small paid pilot can provide better commercial evidence than an unrestricted free account.
What should count towards the first 100 app users?
Use a clearly defined activation event, such as completing a booking or creating a usable report, rather than counting downloads alone. Record registrations separately so drop-off remains visible. For products used by teams, distinguish individual users from customer organisations, because those measures answer different questions about adoption and demand.
When should a new app ask users for referrals?
Ask after a user has completed a meaningful task and expressed satisfaction, rather than immediately after registration. Describe the type of person who would benefit and provide a short message they can forward. If users hesitate, investigate whether the issue is product value, audience fit or the request itself.
Final considerations
The first 100 users should provide evidence about the audience, the problem and the experience of using the app. Direct recruitment makes that evidence easier to interpret because founders can connect behaviour with actual conversations.
Progress is stronger when relevant users complete useful tasks and return without repeated prompting. Improving that pattern is a sounder basis for wider distribution than reaching a registration target alone.