A Proof Checklist for Small Product Claims

Quick scan

• Problem: Small products publish claims they cannot support — not out of dishonesty, but because the claims felt like positioning rather than assertions.
• Approach: A checklist of five claim types with a decision rule for each.
• Why this may help: Naming the claim type makes it easier to decide quickly whether to keep, qualify, or remove, rather than debating each phrase on feel.
• Use this now: Copy your landing page hero and claims into Landing Page Lie Detector, then use the five tests below on anything that gets flagged.

Every product launch involves claims. Most problems are not lies — they are phrases that started as positioning shorthand and never got translated into specifics.

This checklist covers the five types that cause the most trouble for small products at launch.

---

Claim type 1: Quantified outcomes

Examples: "50% faster," "saves 3 hours a week," "reduces errors by half"

Test: Can you state how this was measured, on what sample, and in what context?

• If yes: publish with a source or brief method note adjacent to the claim.
• If not yet: replace with the mechanism instead. "Automates the formatting step" is supportable at launch. "Saves 3 hours" is not.

| ❌ Unsupported | ✅ Supportable | |---|---| | "50% faster than manual review" | "Flags vague claims in one pass without opening a spreadsheet" | | "Reduce errors by half" | "Catches absolute claims and missing proof blocks before publish" |

Do not publish quantified outcomes without a basis. They invite disbelief and are the easiest claims to check.

---

Claim type 2: Social proof counts

Examples: "Trusted by 10,000+ teams," "1,000 happy customers," "used by teams at Stripe and Notion"

Test: Is the number true, current, and specific about what it counts?

• If yes: use it, but state what it counts ("10,000 accounts created" is more precise than "10,000 users").
• If no: replace with a specific observation that is true. At early launch, "Used by solo founders and teams under 20" is more honest than a count you cannot verify.
• Never publish social proof that is not yet true.

| ❌ Unsupported | ✅ Supportable | |---|---| | "Trusted by thousands" (at launch) | "Used in production by three independent teams since April 2026" | | "Teams at Fortune 500 companies use this" (unverified) | Remove until you can verify and name the context |

---

Claim type 3: Absolute quality

Examples: "the best," "industry-leading," "the most accurate," "unmatched"

Test: Compared to what, on what criteria?

Almost always avoidable. Replace with what makes the product specifically good for a specific use case.

| ❌ Unsupported | ✅ Supportable | |---|---| | "The best JSON formatter available" | "Formats, minifies, and inspects tree paths locally in your browser" | | "Industry-leading readability scoring" | "Flesch Reading Ease and Gunning Fog grade level, calculated locally" |

Absolute quality claims signal overconfidence. Specific feature claims signal that someone actually built the thing.

---

Claim type 4: Mechanism claims

Examples: "AI-powered," "smart," "intelligent," "automated"

Test: What does the mechanism actually do? Can you describe it in one sentence?

• "AI-powered" is fine if the next sentence explains what the AI does. Without explanation, it is vague.
• "Smart" almost always needs a concrete replacement.
• "Automated" is fine if you say what is automated.

| ❌ Unsupported | ✅ Supportable | |---|---| | "AI-powered writing assistant" | "Applies structure rules to prompts: adds role, removes hedging, sets format" | | "Smart slug generation" | "Strips stopwords and normalizes to lowercase with hyphens" | | "Automated text cleanup" | "Normalizes casing, removes extra whitespace, and strips control characters" |

---

Claim type 5: Unqualified outcome claims

Examples: "save time," "boost productivity," "improve your workflow," "write better"

Test: What specific part of the work gets faster or better, and by what visible change?

These phrases are usually true in some sense. The problem is they are too broad to be useful or verifiable.

Replace with the specific action or output change:

| ❌ Too broad | ✅ More specific | |---|---| | "Save time on editing" | "Clean spacing, casing, and obvious noise in one paste" | | "Improve your workflow" | "Runs each pass in a separate tool so you fix one thing at a time" | | "Write better copy" | "Flags vague promises and missing proof blocks before publish" |

---

When a number needs a source

Publish a number only when you can answer all three:

1. How was it measured?
2. On what sample or timeframe?
3. In what context does it apply?

If you cannot answer all three: remove the number or replace it with a mechanism claim.

A useful self-check before publishing any claim: "If a skeptical reader asked me to back this up, what would I show them?" If the answer is nothing, the claim needs revision.

FAQ

What about aspirational claims? Can I say what the product is designed to do?

Yes — with that framing. "Designed to reduce the time spent on pre-publish checks" is honest if it is your intent. "Reduces pre-publish time" without qualification is a result claim.

My competitors all use vague claims. Why should I be more specific?

Specific claims are easier to believe. A reader who can verify your claim — even mentally — trusts it more than a broader one they cannot evaluate.

Should I run a Lie Detector check on my own about page?

Yes. About pages often carry the same unsupported claims as landing pages. The pattern is the same: mechanism claims without specifics, outcome claims without basis.