Your app is approved, the link works, and you have a list of thirty places to post it. What is left is a text box, and that is where people stall: describing your own product without sounding like a press release is genuinely hard at eleven at night. The obvious move is to paste the App Store description into a model and ask for five versions.
Two of the venues on that list publish a rule against exactly that, in their own words, on their own guideline pages.
The two rules, quoted
Hacker News, in its site guidelines: “Don't post generated text or AI-edited text. HN is for conversation between humans.” Fetched from news.ycombinator.com/newsguidelines.html on 2026-08-20, and identical to the wording this repo recorded when the tool was built.
Product Hunt's commenting guidelines carry a section under “What To Avoid” headed AI-Generated Comments. It says the site is about person-to-person interactions, that the community wants to hear from real people, and finishes: “No LLMs or Chrome extensions please!” Fetched the same day.
What decides how much they bind you is where each sits. HN's is under “In Comments”, not “In Submissions”. Product Hunt's is in the commenting guidelines rather than its community guidelines, which say nothing about AI at all. On paper, both rules govern comments.
That is not the escape hatch it looks like. On Product Hunt the maker's post is a comment — the first one under your launch, and the part of the page allowed to be personal. On Hacker News, the Show HN page describes the thread as where people try your thing out, give feedback and ask questions, and asks that the project be something you are around to discuss. At both venues, the part of a launch that is you talking is the part the rule covers.
Show HN has a second rule, and it is about the thing, not the text
The Show HN page adds a constraint the site guidelines do not: “Don't post quickly-generated one-offs; anybody can do that now.” That one is aimed at the project rather than the prose. It sits beside a definition of what a Show HN is for — things people can run or hold — with blog posts, sign-up pages and newsletters named as off topic, because they cannot be tried out.
Two of those lines land harder on an iOS app than they look. HN asks that you make it easy to try your thing, ideally without barriers such as signups or emails, and asks you not to post at all if the work is not ready for users. An app behind an account wall, a waitlist or a paid download is a harder Show HN than a web tool — a fact about the venue, not a criticism of your app.
The title cap, measured rather than remembered
Three rules for a Show HN come off those two pages directly. A Show HN title has to begin with “Show HN” — Hacker News's own instruction, not a convention the community drifted into. Submitters are asked not to make titles stand out with uppercase or exclamation points. And nobody is to solicit upvotes or comments, with the Show HN page repeating it for friends specifically.
The fourth constraint is a number, and numbers are the ones worth checking yourself. This repo recorded an 80-character submission cap, measured across the 1,000 most recent stories on HN's public API: a hard cliff at 80, with 21 stories sitting exactly on it, none between 81 and 83, and a couple above only because moderators append tags like [pdf] after the fact.
I re-measured it for this post from HN's own showstories endpoint on 2026-08-20 — 138 Show HN stories, every one fetched rather than scraped off a page.
| Title length | Show HN stories (n = 138) |
|---|---|
| 25–39 characters | 7 |
| 40–59 characters | 30 |
| 60–79 characters | 96 |
| exactly 80 | 5 |
| 81 or more | 0 |
Median 68, mean 65.2, longest 80. Nothing exceeded it and five titles sat precisely on it — the shape a hard limit makes, not a habit. Two measurements, two weeks apart, different slices of the site, same ceiling. The median sits well under the cap, so a title needing all 80 usually needs an edit instead.
The venues are not one audience
The other reason one blurb cannot cover a launch is that the venues want structurally different things. /launch-directories lists thirty places across five groups: Apple's own editorial featuring pitch, eleven launch platforms, three software directories, eight Apple-focused press sites and seven communities.
That list is a directory of other people's websites, so its failure mode is a plain falsehood rather than a bad estimate, and it carries the strictest sourcing on this site. Every URL was fetched and answered before it was added. No prices, turnaround times or audience numbers appear anywhere, since several venues charge for placement and a stale figure is a lie with a shelf life. Seven of the thirty are linked at their homepage with a flag saying so: their submission page rejects an automated check, so the deep URL could not be verified and was not invented.
The same discipline is why this post asserts nothing about any subreddit. Seven communities are on that list; their self-promotion rules differ per community, are enforced by volunteers and change without notice. Read the sidebar and the rules of the exact community you are posting to.
A model told not to invent something is not a model that cannot
The prompt behind /launch-posts is the most restrictive one in this project. The App Store description and the developer's own note are named as the only source of facts. Invented features, user counts, downloads, ratings, revenue, awards, press mentions, funding, team size and roadmap promises are forbidden by name. So is naming or comparing against another app, because the model has not been shown that product. Price may be stated only as Apple's own formatted string — and in-app purchases and subscriptions not at all, since the public listing exposes neither, which makes any mention of them fabrication by definition.
None of that is a guarantee, and the distinction matters more than the instruction does. An instruction in a prompt is a preference expressed to a system that remains free to ignore it. Telling a model not to write “loved by thousands” lowers the odds of it appearing; it does not remove them. Marketing copy is what the model read to learn how launch announcements sound, and social proof is the default shape of that genre.
Which is why the same file checks the output anyway: eleven literal patterns for fabricated social proof — loved by, trusted by, #1, as seen in, award-winning and their relatives — and thirteen more for the marketing register that gets a post ignored on Reddit and flagged on HN.
The checker is narrow on purpose, and its limit is the point. It matches strings, so it catches “award-winning”. It cannot catch a feature your app does not have, because it has never seen your app. A launch draft passes three layers and only one of them knows anything: the prompt asks, the checker greps, and you read it.
Those matches are warnings rather than errors, deliberately. A developer whose own note says they had four thousand beta testers is entitled to write that. The checker cannot see the source, so the honest treatment is to ask whether the claim is literally true rather than to block it.
What a drafting tool can actually verify
| Checkable | Not checkable |
|---|---|
| The 80-character HN title cap, and the 280 characters X allows a standard account | Whether any sentence in the post is true |
| That a Show HN title begins with “Show HN” | Whether the app is ready to be tried, as Show HN requires |
| Capitals and exclamation marks in a Show HN title | Whether a community will accept the post |
| Literal social-proof and marketing phrases | Whether the writing is any good |
| Whether an App Store link carries a campaign token | Whether a rewrite counts as no longer AI-edited |
The token check is there because an untagged launch link produces a graph that went up and no way to attribute it — the subject of a separate post and of /campaign-links.
What this post cannot tell you
Nothing here has a number for what any venue produces. No engagement rate, no conversion rate, no typical Show HN outcome. Those numbers live inside those companies, and a figure nobody can check is worse than none.
Whether these rules are enforced, and how. Both venues describe a moderation process. Neither publishes how it detects generated text, how often it acts, or what follows. A rule that exists and a rule that is caught are different facts, and only the first is verifiable from outside.
Whether a rewrite clears the bar. HN's wording covers AI-edited text as well as generated text, so “I rewrote it” is not automatically outside the rule. Only you know how much of the sentence is still the model's, which is the honest place for that judgement to sit.
Whether the wording still reads this way. Both quotes were fetched on 2026-08-20 from pages that get edited, and the 280-character X figure above is the one this project recorded when the tool was built rather than something re-checked here. The dates are given so you can check rather than trust.
The work splits cleanly: /launch-directories is the verified list of where to post, and /launch-posts drafts a distinct starting point per venue — with Hacker News's rule on screen rather than buried, because a tool that quietly hands you a Show HN draft is not doing you a favour.