I've launched five digital products in the last two months. Every launch artifact — the launch tweet, the Show HN post, the changelog entry, the cold outreach DM, the README intro, the PR description template — was drafted by an AI prompt I'd written, tested, and refined.
This post is those prompts. Not a teaser. The actual prompts, with the actual outputs they produced, and a short note on why each one works. If they're useful, steal them. If you want the full set of 30+ tested prompts covering the entire product lifecycle, I link to it at the bottom.
Why most "launch prompts" are bad
Every AI prompt list I've read has the same problem: the prompts are vague. "Write a launch tweet" produces generic SaaS-speak. "Write a cold email" produces a wall of buzzwords. The model isn't broken — you've given it nothing specific to optimize for, so it optimizes for the average of every mediocre launch tweet it's ever seen.
Every prompt below follows the same four-part structure. If you remember nothing else, remember this:
1. ROLE — Who the model is pretending to be.
2. CONTEXT — The specific product, audience, and goal.
3. CONSTRAINTS— Tone, length, format, what to avoid.
4. OUTPUT — The exact shape of what you want back.
Vague prompts fail because they skip 2 and 3. Every prompt below has all four.
Prompt 1 — The launch tweet
The launch tweet is the single highest-leverage piece of copy you'll write. It has to do five things in 280 characters: hook, name the problem, imply the solution, show proof, and link.
ROLE: You are a developer who just launched a side project.
CONTEXT: I'm launching [PRODUCT], which [ONE-SENTENCE WHAT IT DOES].
The target reader is a developer who has experienced [SPECIFIC PAIN].
They've tried [COMMON ALTERNATIVE] and found it [SPECIFIC FAILURE].
CONSTRAINTS: Maximum 270 characters. No emoji in the first 12 words.
No "we're excited to announce". No hashtag spam. End with a link
placeholder. The hook must be a specific observation, not a question.
OUTPUT: Three different tweet drafts. Label them A, B, C.
Why it works: The "no emoji in the first 12 words" constraint kills the 🚀-openers that make every launch tweet look identical. The "specific observation, not a question" constraint kills the "Tired of slow builds?" template. Forcing three drafts lets you pick the strongest.
Example output (for a fictional config-file generator):
A — I've generated the same tsconfig.json by hand 40 times this year. So I built a generator that outputs a valid one in 6 seconds. Free, no signup: [link]
B — Every new TypeScript project starts with the same 15-minute tsconfig ritual. Mine now starts with a button. [link]
C — tsconfig.json has 60+ options. Most devs copy-paste and hope. There's a better way: [link]
A is the strongest — it leads with a specific number ("40 times"), names the pain, and implies the solution without announcing it.
Prompt 2 — The Show HN title
Show HN is the highest-signal launch channel on the internet. A bad title kills the post before anyone reads it. Hacker News titles have to be factual, understated, and specific — no marketing language.
ROLE: You are a developer writing a Show HN submission.
CONTEXT: I built [PRODUCT], a [ONE-LINE DESCRIPTION].
It's built with [TECH STACK]. The core technical idea is
[SPECIFIC TECHNICAL DECISION]. It's different from [EXISTING TOOL]
because [SPECIFIC DIFFERENCE].
CONSTRAINTS: Title must be under 80 characters. No adjectives like
"amazing", "powerful", "revolutionary". No exclamation marks.
Start with "Show HN:" exactly. The title must describe what the
thing IS, not what it does for the user.
OUTPUT: The title only. Then a 3-sentence first paragraph for the
post body that explains the technical decision and why you built it.
Why it works: Show HN downvotes anything that smells like marketing. Forcing the title to describe "what the thing IS" kills "supercharge your workflow" titles. The 80-character limit forces specificity. Banned adjectives kill hype language.
Example output:
Title: Show HN: A static-site generator for config files (tsconfig, eslint, prettier)
Body: I built a collection of static HTML tools that generate valid config files for JavaScript tooling — tsconfig.json, eslint config, prettier config, and about 35 others. Each tool runs entirely client-side, no backend. The interesting technical decision was generating the output as a downloadable file via Blob URLs instead of a textarea, because it means the output preserves exact formatting and can be committed directly.
Prompt 3 — The changelog entry
Changelogs are read by your most engaged users — the ones who already installed your thing and care enough to check what changed. A good changelog entry is specific, dated, and grouped by impact.
ROLE: You are a maintainer writing a changelog entry.
CONTEXT: This release ([VERSION]) of [PRODUCT] includes these changes:
- [CHANGE 1: what it is and why it matters]
- [CHANGE 2: what it is and why it matters]
- [CHANGE 3: what it is and why it matters]
CONSTRAINTS: Use Keep a Changelog format. Group as Added, Changed,
Fixed, Removed, Deprecated, Security — only include groups that
have entries. Each entry is one sentence, present tense, imperative
mood ("Add X", not "Added X" or "Adds X"). Link to the issue/PR
number if known.
OUTPUT: The full changelog section for this version, ready to paste.
Why it works: Imperative mood is the Keep a Changelog convention but most LLMs default to past tense ("Added a new setting") — the constraint catches it. Forcing one-sentence entries kills the wall-of-text changelog nobody reads. Grouping by impact lets users skim.
Example output:
## [1.4.0] - 2026-07-21
### Added
- Support for generating `.npmrc` files with scoped registry auth ([#42](https://example.com/issues/42))
- A "Copy as CJS" toggle to the lint-staged generator
### Fixed
- Quotes in YAML values are now escaped correctly in the docker-compose output
- The tailwind generator no longer crashes on empty `theme.extend`
Prompt 4 — The cold DM (that doesn't feel like a cold DM)
Cold DMs have a ~2% response rate. The ones that work don't pitch — they offer something specific and useful, then ask one question.
ROLE: You are a developer reaching out to another developer.
CONTEXT: I'm [YOUR NAME], I built [PRODUCT]. I'm messaging
[RECIPIENT NAME] because they [SPECIFIC THING THEY DID OR WROTE
— a blog post, a tweet, an OSS project]. Their work on [SPECIFIC
DETAIL] is relevant because [SPECIFIC REASON]. I am NOT asking
them to buy anything.
CONSTRAINTS: Maximum 120 words. No "I hope this finds you well".
No "I'd love to pick your brain". No attachment in the first
message. The message must contain exactly one specific compliment
about their work, one specific question, and one concrete thing
they can say no to. End with a low-friction exit.
OUTPUT: The DM only, ready to send.
Why it works: The "one concrete thing they can say no to" forces you to make an actual ask instead of a vague "let's connect". The "low-friction exit" makes replying optional, which paradoxically increases reply rate. The specific-compliment requirement kills the "I love your content!" template that gets ignored.
Example output:
Hi [Name] — your post on dependency injection in TypeScript was the clearest explanation I've read. The bit about constructor vs property injection finally clicked for me.
I'm building a set of free config-file generators and I'm curious: when you set up a new TS project, do you start from a template or write tsconfig from scratch? No pitch — just genuinely interested in the workflow. Happy to ignore if busy.
Prompt 5 — The README intro
The first 3 lines of your README decide whether someone stars, clones, or bounces. Most README intros bury the lede.
ROLE: You are an open-source maintainer writing a README.
CONTEXT: [PRODUCT] is a [ONE-LINE DESCRIPTION]. The ideal reader
is [WHO]. The single most important thing they need to know in
the first 5 seconds is [THE KEY VALUE]. It's built with [TECH].
It's different from [ALTERNATIVES] because [SPECIFIC DIFFERENCE].
CONSTRAINTS: The intro must be exactly 4 lines. Line 1 is the
project name as an H1. Line 2 is a one-sentence description with
no buzzwords. Line 3 is a "why" sentence starting with "Because"
or "For". Line 4 is a one-line install command in a code block.
No badges in the first 4 lines.
OUTPUT: The README intro only.
Why it works: Badges-first READMEs push the actual description below the fold on GitHub. The "Because/For" opener on line 3 forces you to articulate the why, not just the what. The install command on line 4 lets impatient users skip the rest.
Example output:
# dev-launch-pack
A collection of 38 free, static-site config-file generators for JavaScript and Python tooling.
For developers who generate the same tsconfig/eslint/prettier/docker-compose files by hand every new project.
bash
npx dev-launch-pack
yaml
Prompt 6 — The bug report template
Bug reports that get fixed fast have a specific shape. This prompt generates the template, not a specific bug — you fill it in.
ROLE: You are a maintainer creating a bug report template.
CONTEXT: [PROJECT] is a [TYPE]. The most common bug categories
are [LIST 3-5]. Contributors often forget to include [WHAT THEY
FORGET]. The maintainers need [WHAT THEY NEED TO DEBUG].
CONSTRAINTS: Use GitHub issue template YAML frontmatter with
name, about, title, labels. Use Markdown checkboxes for steps.
Include a "Steps to reproduce" section with 3 numbered steps.
Include an "Expected vs Actual" two-column table. Include a
"Environment" section with version fields. No free-text-only
sections — everything is either a checkbox, a dropdown, or a
specifically-prompted text field.
OUTPUT: The full .github/ISSUE_TEMPLATE/bug_report.yml file content.
Why it works: Free-text-only sections produce bug reports like "it doesn't work, please fix". Structured fields force contributors to give you what you need. The YAML frontmatter means it shows up in GitHub's "New issue" picker.
Prompt 7 — The PR description
PR descriptions are read by reviewers who are deciding whether to read your code. A good description makes the review faster; a bad one makes the reviewer close the tab.
ROLE: You are a developer opening a pull request.
CONTEXT: This PR [WHAT IT DOES]. It's motivated by [ISSUE OR REASON].
The implementation approach is [APPROACH]. I chose this over
[ALTERNATIVE APPROACH] because [REASON]. Testing done: [WHAT YOU
DID TO TEST IT]. Risk areas: [WHERE A REVIEWER SHOULD LOOK HARD].
CONSTRAINTS: Use this structure: ## Summary (2 sentences max),
## Motivation (1 short paragraph), ## Changes (bullet list, each
bullet a logical change), ## Testing (bullet list of what was run),
## Risk (bullet list of areas needing review). No "This PR fixes
#123" as the only description.
OUTPUT: The full PR description, ready to paste.
Why it works: The "Risk" section is the one most PRs omit and the one reviewers need most. The "alternative approach" line forces you to justify your design, which catches bad decisions before review. Banning "fixes #123" as the only description kills the worst PR template on earth.
Prompt 8 — The launch-day checklist
Launch day is chaos. A checklist generated for your specific product is worth 10x a generic one.
ROLE: You are a product launch manager.
CONTEXT: I'm launching [PRODUCT] on [DATE] on these channels:
[LIST CHANNELS — Show HN, Product Hunt, Twitter, Reddit, etc.].
The product is [TYPE]. I have [N] hours of prep time.
CONSTRAINTS: Output a chronological checklist. Group by "T-7 days",
"T-3 days", "T-1 day", "Launch day", "T+1 day". Each item must be
a specific, checkable action, not a vibe ("Draft the launch tweet"
not "Prepare social"). Include a "what can go wrong" section with
3 specific failure modes and one-line mitigations.
OUTPUT: The full checklist as a Markdown task list.
Prompt 9 — The customer support reply (for angry users)
Angry users become loyal users if you reply well. They become public critics if you don't.
ROLE: You are a founder replying to a frustrated customer.
CONTEXT: The customer [NAME] wrote: "[PASTE THEIR MESSAGE]".
They are frustrated because [THE SPECIFIC PAIN]. Our product
[WHAT HAPPENED — a bug, a delay, a misunderstanding]. We have
[WHAT WE CAN DO ABOUT IT — a fix, a refund, a workaround].
CONSTRAINTS: Maximum 150 words. Acknowledge their specific pain
in the first sentence (not "I'm sorry you're frustrated" — name
the actual thing). Do not use the word "unfortunately". Do not
blame the customer, the system, or a third party. Offer one
concrete next step. Sign off as a human, not "The Team".
OUTPUT: The reply only, ready to send.
Why it works: "I'm sorry you're frustrated" is the most enraging phrase in customer support — it centers the company's feelings, not the customer's problem. Naming the specific pain ("You lost two hours of work because our autosave failed") is the difference between a defused user and a charged-back one. Banning "unfortunately" kills the passive-voice non-apology.
Prompt 10 — The "what should I build next" survey
The highest-signal feature requests come from a one-question survey sent to users who just used your product.
ROLE: You are a product manager writing a follow-up survey.
CONTEXT: [PRODUCT] is a [TYPE]. The user just completed [ACTION].
I want to know [WHAT I WANT TO LEARN — a feature gap, a friction
point, a willingness to pay]. The survey will be sent via
[EMAIL / IN-APP / DM].
CONSTRAINTS: Maximum 2 questions. Question 1 must be open-ended
(not multiple choice) and start with "What". Question 2, if present,
must be a single multiple-choice with an "Other" option. No
demographic questions. No "How likely are you to recommend" (NPS)
— it's noise for early-stage products.
OUTPUT: The survey text only, ready to send.
Why it works: NPS at early stage is vanity. The open-ended "What" question surfaces feature gaps you'd never think to ask about. Capping at 2 questions respects the user's time and increases completion rate.
Prompt 11 — The pricing-page copy
Pricing pages fail when they describe tiers instead of outcomes. Nobody buys "5 seats and 10GB" — they buy "for my team of 4 that ships daily".
ROLE: You are a copywriter writing pricing-tier descriptions.
CONTEXT: [PRODUCT] has [N] tiers: [LIST TIERS WITH PRICES]. The
ideal customer for tier 1 is [PERSONA 1]. For tier 2 is [PERSONA 2].
For tier 3 is [PERSONA 3]. The core differentiator between tiers
is [DIFFERENTIATOR — usage, features, support].
CONSTRAINTS: Each tier description is exactly 2 lines. Line 1
names who it's for ("For solo developers", "For small teams", "For
scaling startups"). Line 2 names the single most important thing
that tier unlocks. Do NOT list every feature — list only the one
that justifies the price jump from the tier below. No "Most
popular" badge unless I specify it.
OUTPUT: The tier descriptions only, formatted for a pricing table.
How to test these prompts
A prompt is code. You wouldn't ship code without running it. Prompts are nondeterministic, so one good generation proves nothing — you need to see how the prompt behaves across runs and edge cases.
My testing process, for every prompt before it ships into a workflow:
- Run it 5 times on the same input. If outputs vary wildly, the prompt is under-specified — add more constraints.
- Run it on 3 edge cases: a tiny product, a huge product, a weird product. If it breaks on edge cases, add input validation to the prompt.
- Score outputs against a rubric you wrote before generating. The rubric forces you to define "good" upfront instead of vibes-checking afterward.
- A/B the prompt against a simpler version. Sometimes the 4-part structure is overkill and a 1-liner works fine. Test it.
The full set
The 11 prompts above are the ones I use most. The full pack I sell covers 30+ prompts across the entire product lifecycle — launch, growth, support, ops — each tested with the rubric process above.
- 🚀 Developer Product-Launch Prompt Pack — $9 — the 11 prompts above plus 20+ more (launch tweet variants, Show HN body, Product Hunt copy, changelog templates, cold email sequences, investor updates, postmortem templates)
- 📚 Developer Productivity Prompt Library — $49 — 30 prompts for daily dev workflow (code review, refactoring, debugging, test writing, architecture docs)
- ✍️ SaaS Marketing Copy Prompt Pack — $49 — 25 prompts for landing pages, ad copy, email sequences, blog outlines
- ⚙️ AI Startup Operations Prompt System — $199 — 50+ prompts + 10 workflow chains (strategy, ops, marketing, sales, product, finance, HR, support)
- 📘 AI Business Transformation Playbook — $999 — 100+ prompts + 12 workflows + 40-point AI opportunity audit + ROI templates + governance policies
Or browse the full storefront. Every pack is tested and refundable via Gumroad. The $9 launch pack is the cheapest way to see if the approach works for you.
No hard sell. If the 11 prompts in this post were enough, great — use them. If you want the rest of the set, tested and ready, the link is there.
TL;DR: 11 tested prompts for shipping products — launch tweet, Show HN title, changelog, cold DM, README intro, bug report template, PR description, launch checklist, support reply, feature survey, pricing copy. Each follows Role → Context → Constraints → Output format. Test prompts like code: 5 runs, 3 edge cases, rubric scoring. Free to use; full 30+ pack linked at the bottom.
Top comments (0)