Define the first cohort before choosing a channel
Write a participant profile using behavior, not a broad label such as anyone with a phone. For a running diary, the profile could be people who already record runs and review progress on a phone. Decide which participants should be new to your category and which should use an alternative product. Include device support, language and time commitment. Separate these practical criteria from assumptions about how positive their feedback will be.
Create a short screening form with the minimum necessary information. Ask about the relevant habit, device and availability. Avoid collecting a home address, sensitive personal details or credentials just to allocate a place. Tell applicants why the questions matter and who will use their answers. When a person does not fit the round, explain that the scope is limited instead of treating them as a low-quality user.
Recruit where the problem is already discussed
Start with people who have asked you about the product, a voluntary waitlist or a relevant professional or hobby community. Read each community's recruitment rules before posting. A useful invitation explains the problem, the test's unfinished nature, required device, time needed and how to participate. Disclose that you work on the app. Do not join unrelated discussions only to drop a test link.
Developer communities can help you catch broken flows, while target users can explain whether the app fits their actual routine. Keep those groups distinguishable in your notes. If you use a participant marketplace or a feedback community such as RateMyApp, check its supported workflow and the distribution platform's rules. Apple's TestFlight guidance prohibits distributing its apps to testers in exchange for compensation. Do not assume that calling a reward credits changes the relevant restriction.
Turn interest into completed sessions
Send the exact access instructions only after the participant understands the task. Include a contact for install problems and the date after which the build or invitation should no longer be used. Try the same instructions yourself from a fresh account. A person who clicks an invitation has not necessarily installed the app; a person who installs it has not necessarily completed the research task.
Track invited, accepted, installed, task attempted and report received as separate states. Ask an appropriate reminder question: did installation fail, is the task unclear or is the timing unsuitable? One relevant follow-up is more helpful than repeated requests for a rating. Give participants a graceful way to decline or leave. Only retain the details needed for the agreed round and remove unnecessary information after you finish.
Repair missing coverage instead of chasing raw numbers
Review the gaps before expanding recruitment. If every report comes from the same recent phone model, recruit for another supported setup. If all participants already know the founder, add people who have not heard the product explanation. For specialized apps, domain understanding may matter more than a large pool. Never claim that a general audience is qualified to assess a sensitive or expert workflow merely because they can install the build.
Measure the cost of a usable report and the time needed to support the cohort. A useful report includes an attempted task and enough context to understand the outcome; it need not be favorable. Keep feedback opportunities open to criticism and distinguish recruitment from public store review requests. The related message template can help you write an invitation, while the participant-count guide helps you decide which coverage gap to fill next.
Working example
Illustrative cohort exercise: you are testing a budgeting app for freelancers. Make three columns: relevant workflow, supported device and available session time. Invite people who already track freelance expenses through a voluntary community post that permits research requests. Ask applicants which expense-recording method they currently use, then select participants across the device setups you need to cover. Give everyone a harmless sample receipt and ask them to save and later locate the expense. Track access trouble separately from product trouble. The aim is evidence about that workflow, not praise from people who want to help the founder or a guaranteed number of app-store stars.
Build a private testing briefYour next steps
- Define the participant's relevant habit, device requirements and realistic time commitment.
- Use voluntary recruitment channels, follow their rules and disclose your relationship to the app.
- Track installation, task attempts and reports separately, with an easy route for support or withdrawal.
- Fill missing user and device coverage, and keep compensation and public-review rules explicit.
Official sources
Sources checked October 3, 2026. Review the current provider documentation before acting on requirements.
Download the free app testing templates
Turn the next test into something useful.
Publish a focused brief on RateMyApp. Credits fund approved private reports; public store reviews are voluntary and unrewarded.
List your app for feedback