I've spent the last year building and running a SaaS almost entirely on AI-generated output — launch copy, code reviews, cold outreach, changelogs, support replies. Along the way I've written, tested, and thrown away something like 400+ prompts. About half of them are now in a curated pack I sell. The other half were just bad.
This post isn't a sales pitch. It's the actual lessons from testing hundreds of prompts: why most of them fail, what a good one looks like, and how to test them systematically instead of vibes-checking. If it's useful, I link to the paid pack at the very end. If it's not, you still walk away with three prompts you can use today.
1. Why most AI prompts fail
Almost every bad prompt I've written fails for one of three reasons. They're all fixable.
Failure 1: Vague instructions
The canonical bad prompt:
Write a tweet to launch my product.
What comes back is generic SaaS-speak — "🚀 We're excited to announce..." followed by three feature bullets and a clunky link. It reads like a press release wearing a costume. The model isn't being lazy; you've given it nothing specific to optimize for, so it optimizes for the average of every launch tweet it's ever seen. The average is bad.
Failure 2: No context
Models can't infer what they aren't told. A prompt like "write a cold email" has no idea who the recipient is, what your product does, or why this specific person should care. So it writes a cold email for a fictional average person. That email will always be worse than one you'd write yourself in five minutes.
Context is the single highest-leverage thing you can add to a prompt. I'll prove it in the examples below.
Failure 3: No testing
Here's the uncomfortable one: most people never test their prompts. They paste one into ChatGPT, glance at the output, say "yeah that's fine," and ship it into a workflow. Then they're surprised when their launch email underperforms.
You wouldn't ship code without running it. Prompts are code. The outputs are nondeterministic, so one good generation proves nothing — you need to see how the prompt behaves across several runs and edge cases before trusting it.
2. The anatomy of a good prompt
Every prompt in my pack follows the same four-part structure. If you remember nothing else from this post, remember this.
1. ROLE — Who the model is pretending to be.
2. CONTEXT — The specific situation, product, audience, goal.
3. CONSTRAINTS — Length, tone, what to avoid, hard rules.
4. OUTPUT FORMAT — Exact shape the response should take.
Here's the skeleton:
You are a [ROLE].
Context:
- Product: [what it is, one sentence]
- Audience: [who will read the output]
- Goal: [what a good output achieves]
Constraints:
- [length / format / tone rules]
- [what to avoid — explicitly]
Output format:
[Describe the exact structure. If you want JSON, give the schema.
If you want a tweet, say so and cap the length.]
That's it. Role, context, constraints, output format. Notice constraints include what to avoid — this matters more than people think. Telling a model "no 'I hope this finds you well,' no 'reaching out'" does more for cold-email quality than any positive instruction.
3. Three prompts, with real outputs
These are lightly edited versions of prompts from my packs. Each one runs the four-part structure. I'll show the prompt and a representative output.
Example A — The launch tweet
You are a senior growth marketer who writes for technical audiences.
Context:
- Product: [PRODUCT NAME], a [ONE-SENTENCE DESCRIPTION].
- Audience: developers and indie hackers on X/Twitter.
- Goal: drive clicks to [LAUNCH URL] and replies/quote-tweets.
Constraints:
- Under 280 characters, including the link.
- Lead with the problem or a specific result, not "we're excited to."
- One concrete number or proof point (speed, price,LOC saved, etc.).
- No emoji pile-ups. Max one emoji, only if it earns its place.
- End with the link and a soft CTA ("try it", "tear it apart", etc.).
Output format:
A single tweet. No preamble, no explanation.
Representative output:
Spent 4 hours formatting changelog entries by hand every release. Wrote a tool that does it in 3 seconds from raw git notes. $9, runs locally, no signup.
[link] — would genuinely value someone tearing it apart.
Notice what the structure bought us: the tweet leads with a problem and a number, the CTA invites scrutiny (which performs better than "check it out!"), and there's no "🚀 excited to announce." That's the constraints doing work.
Example B — The code review prompt
This one lives in the Developer Productivity pack. It turns a raw diff into a structured review.
You are a senior staff engineer doing a careful code review.
Context:
- Diff: paste the git diff below.
- This is a PR to [REPO]. Primary language: [LANGUAGE].
- I want issues that block merge, not nitpicks.
Constraints:
- Group findings as: 🔴 Blockers / 🟡 Should fix / 🟢 Nice to have.
- For each finding: file:line, what's wrong, why it matters, suggested fix.
- Only flag real problems. If the diff is clean, say "No blockers found."
- Do not comment on style if a linter would catch it.
Diff:
[DIFF HERE]
Representative output:
🔴 Blockers
- auth.py:42 — the new token check runs before rate limiting, so a
flood of bad tokens still hits the DB lookup. Move the rate-limit
check above the token verify, or cache negative lookups for 60s.
🟡 Should fix
- auth.py:88 — `except Exception: pass` swallows the error that
debugging will need later. Log it at minimum.
🟢 Nice to have
- auth.py:120 — the helper `is_valid` does the same work as the
existing `validate_token`. Consolidate.
No other blockers found.
What makes this work: the format constraint means the output is scannable and actionable, not a wall of prose. The "if clean, say so" constraint prevents the model from inventing problems to justify its existence — a common failure mode on small diffs.
Example C — The cold email prompt
This is the one I rewrote the most times. Bad cold emails are genuinely worse than no cold email.
Write a cold email to a prospective first user of:
Product: [PRODUCT NAME]
What it does: [ONE SENTENCE]
Why I think THEY specifically would care: [ONE SPECIFIC REASON tied to their work]
Recipient: [NAME / ROLE]
Constraints:
- Under 120 words total.
- Subject line under 50 characters, no clickbait.
- First line references something real they did or wrote (placeholder: [THEIR WORK]).
- One sentence on what the product is.
- One sentence on why I'm emailing them specifically.
- A soft, specific ask (e.g., "Would you be willing to try it and tell me what's broken?").
- Sign off as a real person.
- No "I hope this finds you well." No "reaching out."
Representative output:
Subject: your post on cold-start retention
Hi [NAME],
Saw your writeup on cohort retention curves — the bit about
day-1 vs day-7 dropoff matched what we keep seeing.
I'm shipping [PRODUCT]: [ONE-SENTENCE DESCRIPTION]. I'm emailing
you specifically because your retention framing is exactly the
problem it's built around.
Would you be willing to try it and tell me what's broken? No pitch,
just want honest feedback from someone who thinks about this.
— [YOUR NAME]
The two constraints doing the heaviest lifting here are "reference something real they did" (forces research, kills template energy) and "no 'reaching out'" (kills the single most spam-sounding phrase in cold email). Everything else is structure.
4. How to test prompts systematically
This is the part most people skip, and it's why I trust the prompts I ship.
I run every prompt through a four-step test before it goes into a pack or a workflow:
Step 1 — Run it 5 times
Nondeterminism is real. If a prompt gives you a great output on run 1 and mediocre output on runs 2–5, the prompt is mediocre — you got lucky once. Run it five times and look at the variance. You want a prompt that's consistently good, not occasionally brilliant.
Step 2 — Test on edge cases
Happy-path inputs hide weaknesses. For the cold-email prompt I test on:
- A recipient with almost no public presence (can the prompt handle "reference something real they did" when there's little to reference?)
- A product with a very long one-sentence description (does it still hit 120 words?)
- A recipient who is obviously a bad fit (does the prompt produce something honest, or does it oversell?)
Edge cases are where bad prompts break. Find the breakage before shipping.
Step 3 — Check against a rubric
Define what "good" means before reading the output, so you don't post-hoc rationalize. For the launch tweet, my rubric is: leads with problem or result (✓/✗), has a concrete number (✓/✗), under 280 chars (✓/✗), no "excited to announce" (✓/✗), has a specific CTA (✓/✗). If a prompt's output doesn't pass all five, the prompt needs work, not the output.
Step 4 — Iterate the prompt, not the output
When a test fails, the temptation is to hand-edit the bad output and move on. Don't. Go back and tighten the prompt so the next run produces a passing output on its own. Otherwise you've shipped a prompt that only works when a human fixes its output — which means you haven't actually shipped a working prompt.
5. The full collection
The three prompts above are representative of a larger set I've built and tested this way. The full Developer Product-Launch Prompt Pack has 7 prompts (launch tweet, Show HN post, Reddit launch post, README intro, cold email, changelog entry, waitlist email), every one run through the test process above, with sample outputs included. It's $9:
👉 Developer Product-Launch Prompt Pack — $9
If launch copy isn't what you need, there's also a 25-prompt SaaS Marketing Copy Pack, a 30-prompt Developer Productivity Library (where the code-review prompt above lives), and a larger operations system — but the $9 launch pack is the cheapest way to see if the approach works for you.
No hard sell. If the three 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: Most prompts fail because they're vague, context-free, and untested. Fix all three with the Role → Context → Constraints → Output format structure, test across multiple runs and edge cases, and check outputs against a rubric you wrote before generating. The prompts in this post are free to use. The full pack of 200+ is linked above.
SOCIAL SHARE CARD GENERATOR