How to Ask People to Try Your App (4 Scripts)

Ask for one specific action, put a time bound on it, and give the person a way out. "Check out my app" gets ignored because it has no defined end: the reader can't tell what you want, how long it will take, or when they're allowed to be finished, so the cheapest response is "nice, congrats" and never opening the link. Swap it for "open this one screen, spend two minutes, and tell me the first thing that confused you" and people answer. The four scripts below cover the friend ask, the community post, the cold DM, and the follow-up, and the friend ask is the least valuable of the four even though it's the one you'll reach for first.

Why does "check out my app" fail?

That sentence asks the reader to do three jobs you should have done for them.

First, it makes them design their own task. You've handed over a link with no instructions, so before they can help you they have to decide what "checking out" means. Sign up? Poke at the landing page? Use it for a week? Nobody wants to do unpaid product management for a friend.

Second, it has no end condition. An open-ended favor sits in the mental inbox forever because there's no moment where the person gets to feel done. A bounded favor gets executed and closed. This is the same reason "can I pick your brain sometime?" dies and "can I ask you one question about pricing?" gets answered.

Third, it's asking for judgment when what you actually need is behavior. "What do you think?" produces an opinion, and opinions from people who like you are the least reliable data in software. What you need is to watch someone try to do a thing and note where they stopped.

There's a fourth reason, and it's the uncomfortable one: an unbounded ask reads as "please validate me." That's an emotionally expensive thing to receive. People dodge it politely rather than tell you no.

What makes an ask small enough to say yes to?

A good ask has four properties, and you can check any message you're about to send against them:

• One screen. Not "the app." One screen, one flow, one action. If your app does six things, ask about the one you're least sure of.
• One time box. Two minutes, five minutes, pick a number and say it out loud. The number is the permission slip that lets them stop.
• One question. Not a survey. One question with a short answer. Multiple questions get zero answers more often than one question does.
• One exit. Say, in the message, that "no" is a fine answer. Counterintuitively this raises your yes rate, because it removes the social cost of ignoring you.

Here's the friend version. This is the one you'll send most and value least, which we'll get to in a second.

Script 1: the friend ask

Hey Sam, I built a thing that turns messy meeting notes into a
short summary you can paste into Slack.

Would you open it, try summarizing one real note of your own,
and tell me the first moment you felt confused? About two minutes.

https://your-app.com

If this week is bad, just say "pass" and I'll stop bugging you.

The two words to change: their name and the action. Everything else is scaffolding that works as-is. The action has to be a real verb applied to a real object ("summarizing one real note"), never "try it out."

One more thing that raises the yes rate: give the ask a link that stays live. If your only link is a build that expires, or a signup wall behind a waitlist, half the people who meant to help you will arrive after the window closed. Apple's own TestFlight documentation describes public tester links exactly this way, as the option for when you don't have everyone's email in advance and need something you can paste anywhere. Web apps have the same need. A permanent, public page beats a temporary invite every time.

What should you ask a stranger versus a friend?

Here's the part most advice gets backwards. Friends are the easiest people to ask and the worst people to learn from.

A friend already has context you never gave them. They know what you've been building, they know the elevator pitch from a dinner three months ago, and they want you to succeed. Every one of those things contaminates the test. A friend cannot tell you whether your pitch lands, because a friend was never a cold reader. A friend will also grade on effort. Their "this is great" is a statement about your relationship, not about your product.

So use friends for what they're genuinely good at: finding bugs on a task you specify. "Try summarizing one note and tell me if anything breaks" is a fine friend ask. "Is this a good idea?" is not.

Strangers who have the problem are where the real signal lives. They will bounce for reasons you find insulting and informative. The trade is that you have less social credit with them, so the ask has to be smaller and the value has to flow toward them first.

For communities, the winning move is to lead with the problem you solved, not the thing you built. Show the work. Then make the app the footnote.

Script 2: the community post

I kept losing an hour a week rewriting meeting notes into
something my team would actually read, so I spent two weekends
building a small tool that does the first draft.

Here's what it produces from a real (redacted) note: [screenshot]

The part I'm least sure about is whether the summary is too
short to be useful. If you write notes for a team, would you
look at that screenshot and tell me if you'd paste it as-is?

Tool's here if you want to run your own note through it:
https://your-app.com

The two words to change: the problem in line one and the question you're least sure of. The screenshot matters more than the link, because it lets people give you a useful answer without leaving the thread. Some of your best feedback will come from people who never click anything.

Cold DMs are the highest-friction and lowest-yield of the four, and they're worth sending anyway when you can name a specific reason you're writing to that specific person. The reason is the whole message. Without it you're spam, and both you and the recipient know it.

Script 3: the cold DM

Hi Priya, I saw your post about spending Sunday nights cleaning up
notes from the week. I built a small tool for exactly that problem.

I'm not selling anything, it's free. Would you run one of your notes
through it and tell me whether the output is close enough to paste?

https://your-app.com

Totally fine to ignore this.

The two words to change: the reason (the specific thing they said or built that brought you to their inbox) and the ask. If you can't fill in the reason honestly, don't send the message.

Two hard limits on the stranger side. Don't buy testers, and don't use bulk auto-submission or DM automation. Paid tester farms and coordinated engagement are the exact patterns platform integrity systems are built to catch, and the penalty lands on your account, not the vendor's. Product Hunt is unusually direct about this in its help center: it asks makers not to solicit upvotes at all, and says that asking for or incentivizing votes can push a product down the rankings or off the homepage entirely. Most communities have a version of that rule. Read it before you post, not after you're banned.

If you want reciprocity without the awkwardness, trade an ask for an ask. That's the whole premise of Favors.dev, where builders swap feedback and favors instead of begging for them. Giving three people real feedback before you request any is the cheapest social credit available.

When is the right moment to follow up?

Once, two to three days after the original ask. That's it.

Twelve hours is too soon and reads as pressure. Three weeks is too late, because they've forgotten what you sent and you're effectively cold-asking a second time. Two to three days is long enough that a busy person has cleared their week and short enough that your message is still recognizable.

The follow-up that works doesn't repeat the ask. It gives them a smaller version of it, plus an easy exit, plus one detail that proves you're a person and not a sequence.

Script 4: the follow-up

Hey Sam, no pressure at all on the notes tool.

If you did open it: what happened? Even "I got bored on the
signup screen" is genuinely useful to me.

If you didn't, that's honestly an answer too, and I'll stop here.

The two words to change: the detail (name the thing, not "my app") and the out (make the exit explicit and mean it). Notice that the follow-up offers a guess at the failure mode. Giving someone a plausible negative to agree with is far easier for them than composing criticism from scratch.

Send this one time. If there's no reply to the follow-up, the answer is no, and continuing costs you a relationship for a data point you can get elsewhere. Keep a plain list of who you asked, what they said, and what you fixed as a result. The list is the asset. If you want the wider version of this loop, How to Get Your First 100 People to Try Your App covers where the asks come from in the first place.

What do you do with a "looks great!"?

"Looks great" means one of three things, and all three are the same thing: they did not use it.

They opened the link and bounced. Or they never opened it and are being kind. Or they used it for forty seconds and don't want to write a paragraph about why it didn't stick. None of those is feedback, and treating it as validation is how people spend six months building on top of nothing.

Don't argue, and don't sulk. Ask one unsticking question. These three work:

• "Did you get as far as [specific step]?"
• "Where did you stop?"
• "What would have to be true for you to use this next week?"

The last one is the strongest, because it converts a compliment into a requirement. Answers to it sound like "I'd need it to read my calendar" or "honestly I only do this twice a year," and the second answer is worth more than the first: it tells you this person was never your user, which means the friendly "looks great" was noise you were about to mistake for a signal.

Write down the answer verbatim. Paraphrasing feedback into your own words is how you accidentally launder a complaint into a compliment. If you're building a proper testing round rather than one-off asks, the beta tester checklist covers what to set up before the first person opens the app.

How many asks is too many?

Three limits, in increasing order of how often people blow past them.

Per person: two. The ask and one follow-up. That's the entire budget. A third message converts a favor into an obligation.

Per round: about five, then stop and fix something. This isn't a made-up number. It's the classic usability finding from Nielsen Norman Group that five testers surface most of the problems, after which you mostly rediscover the same issues, and that running several small rounds beats one large one. The practical version for a solo builder: ask five people, watch what breaks, fix the top thing, then ask the next five. Asking thirty people before you fix anything means twenty-five people hit a bug you already knew about, and you've burned twenty-five first impressions to learn nothing new.

Per community: one post, and give more than you take. Every forum, subreddit and Discord has a self-promotion rule and a culture that's stricter than the rule. Post once, answer every reply, and spend more time responding to other people's projects than promoting your own. The builders who get real feedback from communities are the ones who were members before they had something to plug.

The cadence that actually works isn't a blitz. It's a handful of asks a week, forever, with a fix in between. Getting the first 10 users for a side project is a slower and more manual process than most launch advice admits, and that's normal.

One last thing, and it's the reason this whole post exists: every ask should point at a link that keeps working after the conversation ends. DMs scroll away, community posts sink in a day, and a launch page goes quiet by dinner. A listing doesn't. You can list your app free on TryMy, which takes a few minutes, is reviewed by a human, and stays up. Free, free-trial and freemium apps qualify. It won't replace asking people directly, and I'm not going to pretend a listing is a traffic strategy on its own. It's the durable end of the ask, so the person who hears about your app three weeks from now still has somewhere to land.

Frequently asked questions

Should I ask friends and family to try my app?

Yes, but for a narrow purpose. Friends and family are good at finding bugs on a task you specify and terrible at telling you whether the product is worth using, because they have context a stranger won't have and a relationship to protect. Ask them "try this specific action and tell me if anything breaks." Don't ask them "would you use this?" and don't count their enthusiasm as demand.

How do I ask without sounding desperate?

Desperation comes from an open-ended ask, not from asking. "Check out my app, would mean a lot" sounds needy because it's requesting emotional support. "Would you try summarizing one note and tell me where you got stuck? Two minutes, and no is fine" sounds like a competent person running a test, because that's what it is. Specificity, a time bound and an explicit exit do all the work. Sending the same message ten times to the same person is what actually reads as desperate.

What's a good number of people to ask at once?

Five, then stop and fix what they found. Small rounds surface most problems and let you improve between them, which is better than one large round where everyone hits the same bug. Five is also a manageable number of follow-ups to send by hand two days later, and following up is where most of the value shows up.

Is it okay to DM strangers about my app?

It's okay when you can name a specific, honest reason you're writing to that person, the message is short, and you make ignoring it easy. It's not okay in bulk. Automated DM tools, bought testers and coordinated engagement campaigns violate most platforms' rules, and the account that gets restricted is yours. If sending the same message to fifty people would embarrass you, that's the signal to stop and go find a community where sharing your work is the point.