Reply to Launch Comments: Templates for Praise, Requests, Bugs and “How Is This Different?”

What makes a reply worth reading?

It adds something the commenter did not already have. “Thanks!” adds nothing, and a thread made of thank-yous looks like a maker clapping alone. A reply that gives one new fact, such as why you made a choice, how to do the thing they asked about, or what you will change, shows that a person read the comment and thought about it. It also gives the next visitor to the page a reason to stay, because the thread now contains information.

Speed matters as much as content. Someone who comments on a launch is paying attention right then, and a reply within the hour finds them while they are still on the page or in the thread. This page assumes comments arrive in a thread under your launch, as they do on this site, where comments are threaded and you can answer each one directly. The same rules apply on other platforms, though each has its own norms; the answer on responding to launch comments covers the reasoning.

Template 1: replying to praise

The temptation is to write “Thank you so much!!” and move on. Resist it. Name the part they liked, tell them something about it they could not have known, and invite a next step that helps you.

Thanks, [name]. [Repeat the specific thing they liked, in a few words.] That part took the longest because [one true detail about building it].

Out of curiosity: what would you use it for first? [Or: Is there something you wish it did that it doesn't?]

Template 2: replying to a feature request

Be honest about the answer. A vague “great idea, we’ll look into it” on every request makes none of them believable. If the answer is no, say why, because a reason is more respectful than a promise you will not keep.

Good one, [name]. I don't have [feature] yet. [Choose one:]
- It's on my list, probably after [thing that comes first], and I'll post here when it ships.
- It's not planned, because [honest reason, such as scope or maintenance]. In the meantime you could [workaround, if there is one].
- I'm not sure yet. Could you tell me what you're trying to do when you reach for it? That'll help me decide.

[If you add it, reply again to this thread when you ship.]

Keep a list of requests with the names of the people who made them. When you ship one, go back to the thread and tell them. It takes a minute and is the most persuasive thing you can do for a young product.

Template 3: replying to a bug report or harsh criticism

Do not defend. A comment that says the product broke, or is confusing, or is pointless, is a person telling you what happened to them. Even a rude one usually contains a real observation. Pull it out, thank them for it and ask for what you need to look into it.

Thanks for telling me, [name]. That's a real problem if [what they experienced, in your own words so they see you understood].

To track it down, could you tell me [one specific thing: browser or device, what you clicked, what you expected]? You can reply here or email [address].

[If you can fix it:] I'll look today and reply here when it's sorted.
[If the criticism is about scope or design:] I hear you on [the point]. I built it this way because [reason], but you've made me rethink [specific thing].

Template 4: replying to “how is this different from X?”

This question is not an attack. It is a visitor trying to place you. Answer it fairly: say what the other product is good at, and say who should use it instead. That honesty earns more trust than a feature table, and it keeps you from making claims about a product you may not know well.

Fair question. [Other product] is good at [its real strength], and if you need [case where it wins], I'd use it.

[Product name] is different in one way that matters to me: [your one difference, concrete]. That makes it better for [specific person] and worse for [specific case].

[Optional: If you've used [other product], I'd be interested in what you'd miss here.]

What habits keep the thread healthy?

• Reply to everyone, shortly, for the first day or two. A launch with a quiet, attentive maker looks alive. After that, check in once or twice a day.
• Vary the wording. Pasted-in replies are obvious. Keep the structure and change the sentences.
• Never ask for votes in a reply. Ask for opinions. Where a platform bans soliciting votes, as Hacker News does in its published guidelines, it matters.
• Use first names the commenter used. Match their tone: terse for terse, warm for warm.
• Move long troubleshooting out of the thread. Offer an email address after the first exchange.
• Close the loop. When you ship a fix, edit your reply or add one saying so.

What if nobody comments?

That is normal for a new product, and it says little about the quality. Post your maker first comment with a real question in it, share the page where it is welcome and ask a few people who match your target user to try it and tell you what confused them. To get a public thread to reply in, launch your product free and use the launch day checklist to pace the first day. The glossary entry for a maker comment defines the term, and the board’s social app ideas are a good place to see what kinds of questions people ask about products.