A TestFlight link dropped in a group chat usually gets a few installs and almost no feedback. I run a paid testing service, so I'm biased, but most of what works is free, and it's worth trying in this order.

1. Start with people who already know you

Your email list, your Discord, the friends who actually fit your audience. They install because they like you, which is also the problem: they're kind, and they rarely tell you what's broken.

What helps is a small, specific ask. Not "let me know what you think", but "open the app, sign up, and try to log your first workout. Reply with the moment you got stuck." One task and a deadline gets you more replies than a long message.

2. On iOS, TestFlight does the distribution

TestFlight has two kinds of testers:

  • Internal testers are people on your App Store Connect team, up to 100.
  • External testers can be anyone, up to 10,000, by email invite or a public link.

Two things catch people out. The first build you send to external testers goes through Apple's beta app review, so do that a few days before you need the testers. And each build expires after 90 days, so an old link stops working.

The public link is the useful part. Put it wherever your audience already is, and you can recruit strangers without collecting their emails first.

3. On Android, use the Play Console tracks

Google Play gives you three testing tracks:

  • Internal testing: up to 100 testers, no review, the fastest way to get a build onto real phones.
  • Closed testing: testers join through an opt-in link, by email list or Google Group.
  • Open testing: anyone can join from the store listing.

If your developer account is a personal one created after 13 November 2023, there's a catch: you need a closed test with at least 12 testers opted in for 14 days in a row before you can publish to production. Plan for that early. It holds up a lot of the first launches I see.

Outside Play, Firebase App Distribution is the closest thing to TestFlight. You upload an APK or AAB and invite testers by email, but they have to install the Firebase App Tester app first, and some won't.

4. Communities and beta directories

Reddit testing communities, BetaList and BetaFamily are free to post in. They can work, especially if your app is interesting to other makers. Reply rates swing a lot, though, and testers who sign up for fun drift away after a day or two. Follow up personally with anyone who installs.

5. How many testers you actually need

Fewer than you think, for usability. Nielsen Norman Group's research found that about five people per type of user find most of the usability problems. Three rounds of five, with fixes in between, will teach you more than one round of fifteen.

You need more people for crashes on odd devices, and at least 12 for the Google Play rule above, plus a few spare in case someone drops out.

6. Ask them to record, not to summarize

The most useful thing a beta tester can give you is their screen and their voice while they use the app. A written summary tells you what they remember. A recording shows you the twelve seconds where they couldn't find the button.

We see this in our own numbers: across 664 completed sessions on TestFi, recorded sessions averaged 78 out of 100 on our quality score, against 50 for written ones. If a tester is willing, ask them to share a screen recording with you.

7. When paying for testers makes sense

When you need people on the build today, when you need strangers rather than friends, or when you want a recording from every tester without chasing anyone. That's what we built TestFi for: testers install your build on their own phones and record the session, $5.99 a recorded tester or $3.99 for a written report. I wrote up the free and paid options side by side here.

If you try the free routes first and they work, great. That's the cheapest feedback you'll ever get.

Where did your first beta testers come from? I'm curious what's worked for other people.