On this page
To get your first 100 users for an AI app, find a small group with one recurring problem, help them complete that task, and learn which acquisition channels bring people who return. A large launch announcement can bring visitors, but visitors and registrations are different from users who receive value.
Treat 100 as a planning milestone, not a growth prediction. This guide proposes a process you can run with a small team: define a useful outcome, recruit an initial cohort, repair onboarding, then repeat the channels that attract suitable people. The examples and funnel numbers are illustrative, not Theaimart customer results or measured industry averages.
Define what counts as a user
Choose an activation event close to the reason someone would use the app. “Account created” is easy to measure but may happen before the person discovers whether the product works.
| Product | Weak milestone | More useful activation definition |
|---|---|---|
| Meeting assistant | Recording uploaded | A summary reviewed and exported by the participant |
| Coding tool | Extension installed | A suggested change inspected and accepted or deliberately edited |
| Research assistant | First prompt sent | A source-backed answer checked and saved |
| Image tool | Generation started | An acceptable image selected and downloaded |
These definitions still require judgment. An exported answer can be wrong, and accepting a coding suggestion does not prove the change is safe. Pair event data with a small amount of direct feedback about task success.
Document whether “first 100 users” means registered people, activated people or returning people. You can track all three, but do not mix them when evaluating a channel. Exclude staff and test accounts from the acquisition count.
Pick an audience smaller than “people who use AI”
A useful starting statement is: “We help [a specific person] do [a recurring task] under [a constraint].” For example, an illustrative app might help independent podcast editors convert a transcript into timestamped draft show notes while preserving quotes for review.
That statement suggests where to find users, what a demonstration should show and what failure would matter. “AI content platform” provides none of those answers.
Talk to people who already do the work. Ask them to describe their last attempt, current tools, review requirements and the cost of a mistake. Avoid opening with “Would you use an AI app that…?” A hypothetical compliment is weaker evidence than someone showing you the spreadsheet or editing process they use today.
Write down disqualifying conditions too. If the app cannot handle regulated records, do not recruit people who must upload them. If it supports English only, make that clear before an international user invests time preparing a file.
Build a demonstration that answers a buying question
Show a complete input-to-output journey with synthetic or permissioned data. Include the point where the user checks the result. A demonstration that stops at a fluent answer hides the work needed to make that answer usable.
For the podcast example, show the transcript, the generated draft, one correction and the exported notes. Explain the supported file format and what still needs human review. The demonstration should help a potential user decide whether the workflow fits their own episode.
Put the same information on a stable product page:
- Who the tool is for and the task it supports.
- What the user needs before starting.
- A representative output and its limitations.
- The free allowance or price, with any separate service costs.
- Data handling, support and a clear next step.
One clear action is enough. If the next step is trying a sample, do not give equal emphasis to five unrelated signup paths. Use the launch checklist to check that the promised journey works before promoting it.
Recruit a small first cohort manually
Begin with people whose work you understand. Invite a small number to a task-focused session or an asynchronous trial. Explain that you are the developer, why the product may fit, and what feedback would be useful. Respect community rules and give people an easy way to decline.
During a session, let the person drive. Watch for uncertainty: choosing an input, understanding permissions, waiting for a response, judging quality or finding export. Do not rescue every hesitation with an explanation. The confusion you observe is often the next onboarding improvement.
Afterward, record the task, outcome and one significant obstacle. Separate product failures from recruitment errors. Someone who needs a feature you never intended to support may be the wrong audience; several intended users failing at the same step signals a product problem.
Avoid collecting unnecessary private content in research notes. Ask permission before recording a session. You can often capture “could not find export” without retaining the underlying document or generated answer.
Select channels by the job they perform
Relevant communities: learn the vocabulary and constraints
A community is useful when its members already discuss the problem. Answer questions with a method or example that stands on its own. Mention your affiliation when referring to your product and follow the group's self-promotion rules.
Do not paste the same launch message into unrelated groups. A post about reducing transcript cleanup is more relevant to editors than a generic list of AI features. If promotional posts are prohibited, respect that boundary and use another channel.
Marketplaces and directories: support discovery
A listing gives interested people a destination to inspect, but approval does not guarantee traffic. Choose categories that match the actual task. Include current screenshots, prerequisites and pricing rather than a collection of broad AI keywords.
Theaimart supports reviewed listings that point to supported delivery destinations. Read how to publish an AI app for the current flow and store versus directory for the responsibilities to evaluate. Measure whether visitors from a listing activate; a listing view is an earlier event.
Problem-focused content: demonstrate the workflow
Write an article or short tutorial that helps someone perform the task, including the manual alternative. A developer who explains how to check a generated summary gives readers something useful even before they try the app.
Keep claims narrow. “This example preserves timestamps from this input format” is assessable. “The most accurate meeting AI” needs comparative evidence that most early teams do not have. Avoid creating many near-identical pages for slightly different keywords.
Direct outreach: use relevance and restraint
If direct outreach is appropriate, make the connection to the person's public work clear and keep the request small. Offer a relevant sample or a brief trial rather than demanding a meeting. Follow applicable communication rules, platform terms and opt-out requests; obtain local advice where needed.
An early acquisition plan does not require scraping contact lists, sending bulk messages or manufacturing reviews. A smaller group with a well-matched task can provide more useful learning than a large, poorly matched audience.
Instrument the handoff from interest to value
Start with a compact funnel. You need enough information to distinguish a channel problem from a product problem, without logging every interaction.
| Event | What it helps diagnose |
|---|---|
| Qualified product visit | Whether the channel reaches the intended audience |
| Trial or account started | Whether the offer is clear and acceptable |
| Core task attempted | Whether onboarding reaches the actual workflow |
| Useful result completed | Whether the task succeeds |
| Repeat task in an appropriate interval | Whether the product has recurring value |
Use anonymous or pseudonymous identifiers where suitable and honor consent and deletion choices. Do not put prompts, email addresses or confidential filenames into campaign parameters. When referrals are missing, a voluntary “How did you find us?” question can complement event data.
For an illustrative week, suppose a channel produces 80 qualified visits, 20 trial starts and 8 useful task completions. Trial-start rate is 20 divided by 80, or 25%. Completion among trial starters is 8 divided by 20, or 40%. These are calculations from invented planning inputs, not targets to copy.
The small denominator matters. One additional completion moves that second rate by five percentage points. Inspect individual failures and collect more observations before announcing a winning acquisition channel.
Diagnose the bottleneck before adding traffic
If few suitable people visit, revisit channel selection and the demonstration. If people visit but do not begin, examine pricing clarity, credibility, account requirements and whether the promised task is visible.
If people start but fail, inspect product behavior. Common obstacles include unsupported files, long waits without status, confusing API-key requirements and answers that cannot be exported. Sending more traffic into that experience increases the amount of avoidable frustration.
If people complete a task but do not return, ask whether the task actually recurs. A monthly reporting tool should not be judged by next-day activity. Define the expected return interval from the workflow and segment users by their original job.
Keep a short decision log: observation, likely explanation, change, and the next signal to inspect. Change one major part of a small funnel at a time when practical. If you simultaneously change the audience, price and onboarding, the result may be useful operationally but difficult to attribute.
Make retention part of acquisition
Help users reach the second useful task. That may mean saved preferences, clearer import instructions or a reusable template. It does not automatically mean notification campaigns.
Ask a successful user what they would repeat and what would prevent them from doing so. If the app saves a draft but the user must redo formatting every time, improving export may matter more than adding another model.
Offer reminders only where the workflow and permission support them. Give users control over frequency. A referral request is more appropriate after a successful outcome than immediately after account creation. Never require a positive review or reward only favorable feedback.
A practical month of work
Use this as an ordering guide, not a promise that you will reach 100 people in four weeks.
- Clarify the problem. Interview suitable users, define activation and build one complete demonstration.
- Observe a small cohort. Watch task attempts and repair the most frequent blockers.
- Test a few channels. Publish a relevant listing and one useful explanation, then compare qualified visits and completions.
- Repeat what brings value. Improve the best-fitting channel, investigate return behavior and update public promises.
For a paid acquisition experiment, set a spend limit and include support and inference costs when evaluating the result. Cost per signup alone can hide a channel that attracts expensive, unsuccessful trials.
Your next step
Write an activation definition and invite a small, relevant cohort to complete one real task. Observe the result before broadening distribution. Once the path works, keep a channel only when it brings people who can use the product successfully and have a reason to return.
If the product is ready for a public destination, prepare its listing with the publishing guide. Explore the AI Apps category for related distribution and product-evaluation guidance.