How to Get Your First 10 Testers for a New App

How do I find my first 10 testers?

Start with people who fit your audience and have the problem today: friends and colleagues in that group, a community where they already gather, and other builders who swap testing. Give each tester one task to try, watch or ask what confused them, and fix the biggest problem before inviting more.

Where to find them

• People you know in the target audience, not just supportive friends.
• Communities where the audience meets: subreddits, Discord servers, Facebook groups, Threads. Help first and follow each community's rules.
• Tester exchanges among indie developers, useful for Google Play's closed testing.
• Your waitlist, if you have one.

How to invite them

• iPhone: TestFlight with an external group or public link.
• Android: Google Play internal or closed testing, or a direct APK.

What to ask them to do

"Create an account and plan your first trip" is better than "tell me what you think". Afterwards ask: what did you expect to happen, and where did you hesitate?

Turn what you see into fixes

Write down every hesitation. When three testers stumble at the same spot, that is the next fix.

Recruit people who can teach you something

A tester can help in two ways: find technical failures or show whether the product solves the intended problem. Another developer may catch a navigation bug, while a restaurant manager can tell you whether updating a menu is practical during service. Try to include both types when relevant.

Ten is a useful small target, not a guarantee of validation. The quality of the tasks and observations matters more than reaching a round number.

Make the invitation specific

Explain what the app does, who it is for, which device is needed and one task to try. For example: 'I am testing a simple meal planner for people who cook for one. Could you plan three dinners and tell me where you get stuck?'

Ask for a manageable effort. Do not surprise someone with a long questionnaire or a requirement to create multiple accounts after they agreed to a quick trial.

Give them a safe test environment

Use sample data where possible. If the product touches payments, use test mode and say so. Do not ask someone to enter sensitive real information into an unfinished prototype just to make the screens look populated.

Check the installation route yourself. A beta invitation that cannot be opened consumes the tester's patience before they reach the app.

Observe a task without teaching it

Tell the person what they want to accomplish, then watch their choices. Avoid explaining the location of every button. If you intervene, note where you did so.

Afterward ask what they expected and what they currently use for the task. Separate a confusing interface from a product they do not need. Both can produce abandonment, but the fixes differ.

Keep a concise feedback log

Observation	Useful next action
Could not find saved meals	Review navigation and wording
Save failed on a slow connection	Reproduce the request and error handling
Did not return after the test	Ask whether the task recurred and why they chose another tool
Requested export	Understand who receives it and what information matters

Prioritize severe blockers and repeated problems in the target audience. Do not automatically build every idea a tester suggests.

Close the loop

Thank people and explain which issue changed. Ask affected testers to repeat the original task in the corrected build. Keep their contact details private and respect their preferences about further messages.

If you are recruiting for Google's qualifying closed test, remember that its account-specific opt-in requirements are separate from the general goal of learning from ten people. A useful usability test does not automatically satisfy a store's production-access rules.

Should I pay people to test?

Compensation can recognize time, but it should not buy positive feedback or fabricated participation. Be clear about the task and what you are learning. Follow the relevant platform and community rules.

Can friends provide useful feedback?

Yes, especially when they match the audience. Ask for observable tasks and honest difficulties rather than approval. If they need repeated guidance, record that even if they say they liked the app.

What if nobody accepts the invitation?

Review the audience, the explanation and the effort requested. The task may sound unclear or the installation may be inconvenient. That is useful distribution feedback, but it does not by itself prove nobody needs the product.

How much should I change between testers?

Fix severe blockers promptly. For smaller improvements, keep a note of which version each person tried so the observations remain comparable. Avoid changing everything after every individual preference.

What comes after ten?

Invite a slightly wider group once the main task works and you can support them. Keep measuring actual use and asking why people return or leave. More testers are useful when they answer a next question, not simply because the original round number was reached. The same principle applies to a store beta and a small private trial.

Make feedback easy to send

Offer one clear route for the tester to report a problem, with the task and build version already explained. A short message or screenshot can be enough. Avoid requiring a long form before someone can tell you that installation failed. Reduce the effort to report the first obstacle so you learn what prevented the rest of the test.

Build it with RNBlocks

Use RNBlocks to create the small working app your testers can try. Keep their task focused, refine what blocks it and prepare the appropriate installed beta with our publishing agent. Start free with a concrete journey rather than waiting to finish every planned feature.