Your app works, but nobody is using it yet? These 10 free prompts help you work out who your first users are, find where they already talk, share your launch without spamming, and learn from what they tell you.
Launch prompts for builders: find your people, share without spamming, and learn from your first users.
10 prompts in 4 sections. Replace everything in [BRACKETS IN CAPS], then copy and paste into your AI tool.
ChatGPT or Claude: every prompt only needs the details you type in, like who your app is for, a community's pasted rules, or your users' feedback. No code access needed.
Your own words: Prompt 3.3 (Show HN) has the AI check readiness and ask questions without writing your post, because the Hacker News guidelines ask for no generated or AI-edited text.
Written for use with ChatGPT or Claude. Not yet tested against them.
Use this when you'd describe your users as "everyone" or "anyone who wants to save time," and you can't get more specific. It's for narrowing down to one kind of person you can actually find and talk to.
Fill in: [WHAT MY APP DOES] (e.g. "splits shared grocery bills between roommates"), [WHO I THINK IT'S FOR] (e.g. "people with roommates"), [WHY I BUILT IT] (e.g. "my roommates and I kept arguing over grocery receipts"), [ANYONE WHO HAS USED IT SO FAR] (e.g. "my two roommates", or "nobody yet").
Help me figure out exactly who my first users should be. I'm a beginner at marketing, so keep it plain and practical.
What my app does: [WHAT MY APP DOES]
Who I think it's for: [WHO I THINK IT'S FOR]
Why I built it: [WHY I BUILT IT]
Anyone who has used it so far: [ANYONE WHO HAS USED IT SO FAR]
Please:
1. Ask me up to 5 short questions if anything above is too vague to work with. Wait for my answers before going on.
2. Suggest 3 narrow groups of people who are most likely to feel this problem often and badly enough to try something new. Make each one specific (for example "college students splitting rent in their first apartment," not "young people").
3. For each group, describe in plain words: the moment they feel the problem, what they do about it today, and the words they'd use to describe it.
4. Pick the one group that's easiest for me to reach and talk to first, and explain why.
5. Write one sentence I can use to describe my app to that group: who it's for, the problem, and what it does. No buzzwords.
Don't invent statistics or market sizes. If you're guessing, say it's a guess.
Tips to customize: Your first group can be small. A narrow group you can actually find is easier to start with than a big one you can't. If you built the app for your own problem, you're probably in the first group yourself, so add "I'm one of these people: [HOW YOU FIT IN]" to the prompt.
1.2 Find the Places My Users Already Hang Out
Untested: not yet run against a model.
Use this when you know who your app is for but not where to find them online. It's for making a short list of real communities to check, and how to be useful there before you share anything.
Fill in: [MY FIRST USER] (the group you picked in Prompt 1.1, e.g. "college students splitting rent in their first apartment"), [THE PROBLEM IN THEIR WORDS] (e.g. "who owes what for groceries"), [PLACES I ALREADY USE] (e.g. "I'm active on X and in two Discord servers", or "none").
Help me find where my first users already gather and talk online, so I can join in and be helpful before I ever share my app.
My first user: [MY FIRST USER]
The problem in their words: [THE PROBLEM IN THEIR WORDS]
Places I already use: [PLACES I ALREADY USE]
Please:
1. List 8 to 10 kinds of places where these people might talk about this problem: for example subreddits, Discord or Slack groups, forums, Facebook groups, newsletters, or hashtags.
2. Only name a specific community if you're confident it exists. Mark every name "check this exists" so I look it up myself. Don't make up names, sizes, or activity levels.
3. For each place, tell me what I'd search for to find it, and what I'd look for to judge whether it's active and a good fit.
4. Tell me which places I already use might be the best start, since people there may already know me.
5. For the top 3, suggest 3 ways to be genuinely useful there for a week or two before I mention my app, like answering questions about the problem itself.
Remind me to read each community's rules before posting, because many have their own rules about sharing your own work.
Tips to customize: Search the problem in your users' words, not your app's name, since nobody is searching for an app they haven't heard of. When you find a good place, take a few minutes to read the top posts and the comments. You'll learn how people there talk, which is gold for your launch post later.
1.3 Read the Room Before I Post
Untested: not yet run against a model.
Use this when you've found a community and want to share your app there without breaking its rules. It's for reading the rules and the culture, then planning a post that fits.
Fill in: [THE COMMUNITY] (e.g. "a subreddit for first-time renters", or "a Discord server for indie game makers"), [THEIR RULES] (paste the rules or sidebar text), [A FEW POPULAR POSTS] (paste 2 or 3 titles or short summaries of well-liked posts), [HOW ACTIVE I'VE BEEN THERE] (e.g. "I've answered a few questions this month", or "I just joined").
Help me understand whether and how I can share my app in this community without breaking its rules or annoying people. Don't write a post yet.
The community: [THE COMMUNITY]
Their rules: [THEIR RULES]
A few popular posts: [A FEW POPULAR POSTS]
How active I've been there: [HOW ACTIVE I'VE BEEN THERE]
Please:
1. Using only the rules I pasted, tell me plainly: is posting about my own app allowed here? If yes, under what conditions (for example a certain thread, day, tag, or flair)? Quote the rule you're relying on.
2. If the rules don't say, tell me so, and suggest I message the moderators to ask instead of guessing.
3. Based on the popular posts, describe what kind of post does well here: questions, stories, lessons, screenshots, or something else.
4. Tell me honestly whether I've been active enough here to share my own work yet, and what to do first if not.
5. Suggest one post idea that would be useful to this community even if nobody clicked my link.
Tips to customize: Reddit's own rules ask you to take part authentically in communities you have a personal interest in, and its spam help page says moderators decide what counts as spam in their communities. Its moderator help page notes that some communities don't allow any promotional content, while others use a "10% rule": only 10% of your posts and comments in that community should be self-promotional. Every community is different, so always go by its own rules.
Section 2: Warm Up Before Launch Day
2.1 My 7-Day Launch Plan
Untested: not yet run against a model.
Use this when you want to launch soon, and your only plan so far is to post the link somewhere. It's for a simple week of small daily steps, with real conversations before launch day and follow-up after.
Fill in: [WHAT MY APP DOES], [MY FIRST USER], [MY TOP 3 PLACES] (from Prompts 1.2 and 1.3), [LAUNCH DAY] (e.g. "next Thursday"), [HOURS I HAVE EACH DAY] (e.g. "about 1 hour after school or work"), [WHAT A GOOD RESULT LOOKS LIKE] (e.g. "10 people try it and 3 talk to me about it").
Make me a simple 7-day launch plan I can actually follow. I'm a beginner and don't have much time, so keep each day small.
What my app does: [WHAT MY APP DOES]
My first user: [MY FIRST USER]
My top 3 places: [MY TOP 3 PLACES]
Launch day: [LAUNCH DAY]
Hours I have each day: [HOURS I HAVE EACH DAY]
What a good result looks like: [WHAT A GOOD RESULT LOOKS LIKE]
Please:
1. Lay out the 4 days before launch, launch day, and the 2 days after, with 1 to 3 small tasks per day.
2. Put real conversations first: in the days before launch, plan to help people and talk about the problem in my top places, and to message a few people I know personally.
3. On launch day, plan where to post, in what order, and when I'll be around to reply to comments.
4. After launch, plan time to reply to everyone, thank people who tried it, and ask a few of them for a short chat.
5. Add a short checklist for the day before: the app works on a phone, signup works, and there's an easy way for people to reach me with feedback.
6. Tell me what to write down each day so I can tell whether it worked.
Don't promise any numbers. Keep the goal focused on learning, not just signups.
Tips to customize: If your app isn't ready for strangers yet, push launch day back and spend the extra days on conversations. For a technical check before launch, the Vibe Code Starter Pack's Prompt 6.3 is a launch readiness checklist. If you expect a crowd all at once, our Survive Your First Traffic Spike pack can help you prepare.
2.2 Personal Messages to People I Know
Untested: not yet run against a model.
Use this when you want to tell friends, classmates, coworkers, or past contacts about your app without sounding pushy. It's for short, personal messages that ask for honest feedback, not favors.
Fill in: [WHAT MY APP DOES], [WHO I'M MESSAGING] (e.g. "a friend who complains about splitting bills", "a former classmate who runs a small shop"), [HOW I KNOW THEM] (e.g. "we lived together freshman year"), [WHAT I WANT FROM THEM] (e.g. "try it for one week and tell me what's confusing").
Help me write a short, personal message to someone I know, telling them about my app and asking for honest feedback. It should sound like me texting a friend, not like an ad.
What my app does: [WHAT MY APP DOES]
Who I'm messaging: [WHO I'M MESSAGING]
How I know them: [HOW I KNOW THEM]
What I want from them: [WHAT I WANT FROM THEM]
Please:
1. Write 2 versions: one very short (2 or 3 sentences) and one a little longer (up to 5 sentences).
2. Mention why I thought of this person specifically.
3. Ask for one small, clear thing, like trying it once or telling me what's confusing. Make it easy to say no.
4. Don't ask them to like, upvote, or share anything. Ask for honest feedback instead.
5. Keep it plain: no hype words, no exclamation-point overload, no fake urgency.
I'll send each message one at a time, to people I actually know, and edit it to sound like me.
Tips to customize: Send these one by one and change a detail for each person, rather than pasting the same message to everyone. Platforms frown on mass messaging: Reddit's spam policy lists sending large amounts of unsolicited private messages, X's spam policy lists bulk unsolicited replies, mentions, and direct messages, and Product Hunt asks you not to mass-message people asking for upvotes. A handful of real messages beats a hundred copies.
Section 3: Launch Posts That Don't Feel Like Ads
3.1 One Launch Story, Three Ways
Untested: not yet run against a model.
Use this when you need a launch post for X or a community like a subreddit, and your drafts sound like an ad. It's for three different angles on the same post, written in your voice and fitted to where it's going.
Fill in: [WHAT MY APP DOES], [MY FIRST USER], [WHY I BUILT IT], [ONE REAL DETAIL FROM BUILDING IT] (e.g. "I rebuilt the receipt scanner three times before it read crumpled receipts"), [WHERE I'M POSTING] (e.g. "X", or "the subreddit from Prompt 1.3"), [THAT COMMUNITY'S RULES] (paste them, or write "none, it's my own X account").
Help me write a launch post for my app. Give me three versions using different angles, so I can pick the one that sounds most like me.
What my app does: [WHAT MY APP DOES]
My first user: [MY FIRST USER]
Why I built it: [WHY I BUILT IT]
One real detail from building it: [ONE REAL DETAIL FROM BUILDING IT]
Where I'm posting: [WHERE I'M POSTING]
That community's rules: [THAT COMMUNITY'S RULES]
Write 3 versions:
(a) Story: why I built it and what happened along the way.
(b) Problem: start with the problem my users have, in their words, then how I tried to solve it.
(c) Demo: show what it does in a few short steps, as if describing a short screen recording.
For every version:
1. Fit the length and style to where I'm posting, and follow the rules I pasted. If the rules seem to forbid this kind of post, tell me instead of writing it.
2. Be honest that I made it. Don't pretend to be a user who discovered it.
3. End with one clear, low-pressure ask, like "I'd love to hear what's confusing." Never ask for upvotes, likes, or reposts.
4. Use only the facts I gave you. Don't invent numbers, users, reviews, or results. Mark anything I should fill in.
5. Use plain words, no buzzwords, and no more than one or two emojis or hashtags.
Then tell me which version you'd pick for this place, and why.
Tips to customize: Rewrite the version you pick in your own words before you post. Some communities don't welcome AI-written posts, and people can often tell. Post it when you can stay around to reply for the first hour or two. Don't paste the same post into many communities at once. Reddit's help pages list mass-posting repetitive content, and repeatedly posting the same or similar comments across communities, as spam. X's spam policy lists repeated identical or nearly identical posts too.
3.2 Get Ready for Product Hunt
Untested: not yet run against a model.
Use this when you plan to launch on Product Hunt and want your launch page and first comment ready ahead of time. It's for drafting each part while following Product Hunt's own launch guidance.
Fill in: [MY APP'S NAME], [WHAT MY APP DOES], [MY FIRST USER], [WHAT MAKES IT DIFFERENT] (e.g. "it reads crumpled paper receipts, not just digital ones"), [THE STORY BEHIND IT], [TOOLS I BUILT IT WITH] (e.g. "Lovable and Supabase").
Help me prepare my Product Hunt launch page. I'm launching for the first time, so explain anything I might not know.
My app's name: [MY APP'S NAME]
What my app does: [WHAT MY APP DOES]
My first user: [MY FIRST USER]
What makes it different: [WHAT MAKES IT DIFFERENT]
The story behind it: [THE STORY BEHIND IT]
Tools I built it with: [TOOLS I BUILT IT WITH]
What I know from Product Hunt's Launch Guide and Help Center:
- The tagline is capped at 60 characters, and the description at 260 characters.
- Each launch can have up to three topics.
- The first comment, the maker comment, should introduce the product, the team, what makes it unique, and the story behind the build.
- Product Hunt asks for plain language: say what the product does so someone gets it on the first read.
- Launches go live at 12:01 AM Pacific time on the scheduled date, and I can save a draft first.
- Never ask outright for upvotes. Ask people to visit and comment instead.
Please:
1. Write 5 tagline options, each 60 characters or fewer. Count the characters for each.
2. Write 2 description options, each 260 characters or fewer. Count the characters.
3. Suggest up to 3 topics that fit, and tell me to check them against the topics Product Hunt actually offers.
4. Draft a maker comment in a friendly, honest voice that ends by inviting feedback. Mark anything I need to fill in.
5. List the images and short demo I should prepare, and what each one should show.
6. Write a short message I can share with people I know on launch day that asks them to visit and comment if they're interested, never to upvote.
Use only the facts I gave you. Don't invent users, reviews, or results.
Tips to customize: Product Hunt's Help Center says you need a personal account to post, new accounts have to finish onboarding first, and it recommends posting your own product. Its Launch Guide suggests joining in on Product Hunt ahead of time, picking a day when you can be around to answer comments, and checking that everything works in production before you go live. Read the current Launch Guide before you schedule, since details can change.
3.3 Is My App Ready for Show HN?
Untested: not yet run against a model.
Use this when you're thinking of sharing your app on Hacker News as a Show HN. It's a readiness check against the Show HN guidelines, and it leaves the writing to you, because Hacker News asks for that.
Fill in: [MY LIVE URL], [WHAT MY APP DOES], [HOW SOMEONE TRIES IT] (e.g. "open the link and use it right away, no signup", or "sign up with email first"), [WHAT I BUILT MYSELF AND WHY] (a few notes in your own words), [MY DRAFT TITLE] (written by you, starting with "Show HN:").
I'm thinking about posting my app as a Show HN on Hacker News. Check whether it's ready, using the rules below. Hacker News asks people not to post generated or AI-edited text, so do NOT write or rewrite my title or post. Only ask questions and point out problems. I'll write every word myself.
My live URL: [MY LIVE URL]
What my app does: [WHAT MY APP DOES]
How someone tries it: [HOW SOMEONE TRIES IT]
What I built myself and why: [WHAT I BUILT MYSELF AND WHY]
My draft title: [MY DRAFT TITLE]
What I know from the Show HN guidelines and the Hacker News guidelines:
- Show HN is for something you've made that people can try. Sign-up pages, landing pages, newsletters, and blog posts don't count.
- It should be non-trivial, something I worked on personally and will be around to discuss.
- It's best if people can try it without barriers like signups or emails.
- The title should begin with "Show HN".
- Titles shouldn't use uppercase or exclamation points to stand out, or say how great something is.
- Don't ask friends to upvote or comment.
Please:
1. Go through each rule above and tell me "OK", "Problem", or "Not sure" for my app, with one line on why.
2. If people have to sign up first, help me think through whether I could offer a way to try it without signing up.
3. Point out anything in my draft title that may break the title rules, without rewriting it.
4. Ask me 5 questions that people on Hacker News might ask about how and why I built it, so I can prepare honest answers in my own words.
5. If it isn't ready, tell me plainly, and what would need to change first.
Tips to customize: If your app is only a landing page or waitlist right now, wait until people can try it, since the Show HN guidelines ask you not to post until it's ready. Read the Show HN and Hacker News guidelines yourself before posting; they're short. When people comment, reply in your own words, since the Hacker News guidelines also ask that comments not be generated or AI-edited.
Section 4: Learn From Your First Users
4.1 Feedback Interview Script for My First 10 Users
Untested: not yet run against a model.
Use this when people have tried your app and you want to learn what's working and what isn't. It's for a short, friendly chat script that gets honest answers instead of polite compliments.
Fill in: [WHAT MY APP DOES], [WHO I'M TALKING TO] (e.g. "a student who signed up last week and used it twice"), [WHAT I MOST WANT TO LEARN] (e.g. "why people stop after the first try"), [HOW LONG THE CHAT IS] (e.g. "15 minutes on a video call", or "a few messages in a DM").
Write me a short feedback interview script for a user who has tried my app. I want honest answers, not compliments.
What my app does: [WHAT MY APP DOES]
Who I'm talking to: [WHO I'M TALKING TO]
What I most want to learn: [WHAT I MOST WANT TO LEARN]
How long the chat is: [HOW LONG THE CHAT IS]
Please:
1. Start with a friendly opener that thanks them and says honest criticism helps me most.
2. Ask about what they actually did, not what they might do. For example "Tell me about the last time you had this problem," not "Would you use this?"
3. Include questions about: what they were trying to do, where they got stuck or confused, what they expected that didn't happen, and what they used before.
4. Keep every question open-ended and neutral. Don't describe my app as great or ask leading questions.
5. Add 2 or 3 follow-up questions for when they say something interesting, like "Can you show me?" or "What happened next?"
6. End by asking if I can follow up later, and if they know one other person with the same problem.
7. Fit it to the length I gave, and mark which questions to skip if time runs short.
Tips to customize: Listen more than you talk, and don't defend your app while they're speaking. If you want to record the chat, ask first. Write down their exact words right after, since you can reuse them later in your landing page copy and launch posts.
4.2 Turn Feedback Into a Fix List
Untested: not yet run against a model.
Use this when you've collected feedback from messages, comments, and chats, and you don't know what to work on first. It's for sorting it all into a short, ordered list of what to fix next.
Fill in: [ALL MY FEEDBACK] (paste comments, messages, and interview notes, with names removed), [WHAT MY APP DOES], [MY FIRST USER], [HOURS I HAVE NEXT WEEK] (e.g. "about 6 hours").
Help me turn all my user feedback into a short, ordered fix list. Don't change any code. This is planning only.
All my feedback:
[ALL MY FEEDBACK]
What my app does: [WHAT MY APP DOES]
My first user: [MY FIRST USER]
Hours I have next week: [HOURS I HAVE NEXT WEEK]
Please:
1. Sort every piece of feedback into groups: bugs, confusing parts, missing features, and things that aren't about my app.
2. Merge items that say the same thing in different words, and count how many different people mentioned each one.
3. Separate what people did (got stuck, gave up, came back) from what people said they'd like. Give more weight to what they did.
4. Flag feature requests from people who aren't my first user, so I don't build for the wrong group.
5. Rank the top 5 items by how many of my first users each one affects and how much it gets in their way, and give each a rough effort guess (small, medium, large).
6. Pick what fits in the hours I have next week, and tell me what to ignore for now and why.
Use only the feedback I pasted. Don't invent user counts or quotes.
Tips to customize: Fix one thing at a time, then tell the people who reported it that it's fixed. That small message shows people you listened. If the top item is a stubborn bug, our Fix My Bugs pack can help. If it's a confusing screen, try Make It Pretty.
