Keeping Marketing Honest - Playbook

The rule

Every public claim is one of two things: pure positioning, or a fact backed by real data and a working feature. There is no third category, and there is no "we will make it true later."

"Built for roofers, realtors, and trades" is positioning. It describes who the product is for, and it needs no proof. "Trusted by 12,480 trades" is a fact claim, and it needs 12,480 real trade users or it does not ship. Telling the two apart is the work.

Why this is not optional

It is tempting to treat marketing honesty as a nicety. It is not. False or unsubstantiated claims are deceptive trade practices under consumer-protection law, the kind with fee-shifting statutes attached. Fake review scores and invented user counts are their own category of violation. A single fabricated testimonial on a pricing page is not a copy problem, it is legal exposure. So the bar is not "is this persuasive," it is "could I defend this in front of a regulator."

The first failure mode: the AI invents proof

Point an AI at "write a compelling landing page" and it will, by default, manufacture everything a landing page usually has: named testimonials from people who do not exist, precise-sounding KPIs with no source, a trust badge for an award you never won, logos of integrations you never built, a pricing block and a free-trial offer you never set up. None of this is malice. The model has seen a million landing pages and it is pattern-completing. The fabrications look exactly right, which is what makes them dangerous.

Early in this project, exactly that shipped and had to be ripped out in a hurry: fabricated named-person testimonials, invented usage numbers, a made-up "12,480 trades" badge, integration claims (a well-known field-service tool, an accounting tool, a chat tool) with zero code behind them, and a fabricated pricing and trial block. Every one of those was the AI being helpful in the worst way. The lesson: you are the fact-checker, and the AI is a fluent, confident source you can never take at its word on a claim.

The second failure mode: claims rot

The subtler problem is the true claim that quietly goes false when the product changes underneath it. You move a feature from one plan to another, and now three pages across the marketing site say it costs something it no longer costs. Nobody wrote a lie. The lie accreted.

This happened here: a feature was made free, the headline pricing tiles were updated, and two other surfaces (a pricing FAQ and a privacy-policy plan list) kept saying it was a paid feature, live, for a couple of hours, until someone caught it. The fix was a discipline: whenever a feature's tier, availability, behavior, or name changes, audit every marketing surface that mentions it, with a literal text search across the whole marketing tree, before the change ships. Not just the feature's name, but the tier-coupled phrases ("a Pro feature," "unlimited on Business") that go stale even when the name does not.

The discipline

Underclaim by default. When a claim is tempting but unproven, drop it. "Free to start, no credit card, cancel anytime" is always available because every word is true today. Reach for that before you reach for a number you cannot source.
Every metric, badge, and guarantee needs a real source and a working feature. A money-back guarantee is not a copy line, it is a refund flow plus the policy plus the wiring. If the feature is not there, the claim is not either.
Audit all surfaces when a feature moves. The text search is the tool. Run it before the PR, not after a customer notices.
Name competitors only on honest comparison pages, and only with a "where they win" line, so the page is a resource and not a hit piece.

How it became enforced

This is the same arc as every other discipline in the course: a convention that got missed, then became a gate. After claims rotted one too many times, the build itself started failing when a feature lacked marketing coverage or a help article. The principle about auditing every surface was literally written into the project's rulebook the same session the audit was missed. The honesty is no longer something to remember. For the parts that can be checked mechanically, the deploy will not go out without them.

Honest claims, honest voice

There is a second kind of honesty in the copy, and it is about how the writing sounds. The AI hands you fluent, confident prose that reads as generated, and on a product whose whole pitch is "check the receipts," writing that sounds auto-generated quietly undercuts the claim before a reader reaches a single number.

The tell is cadence, not vocabulary. Three patterns do most of the damage: the "it is not X, it is Y" construction used as the default sentence shape, every section landing on a tidy aphorism, and parentheses standing in for the em-dashes the style rule already banned, which keeps the exact interrupted rhythm the ban was meant to remove. Each is fine once or twice. As a habit they are the prose equivalent of a default font, and a reader feels it even when they cannot name it.

The fix follows the same convention-to-gate arc as everything else, with one deliberate exception. The em-dash rule is a hard build gate. The other three are not, because a machine told to hard-fail them will obediently flatten every sentence into one uniform shape, which is its own slop. So they get reported, by a small slop-check script that counts the densities, and a human reads the number and decides. This playbook is the worked example: a first draft tripped all three, the densities were measured, and the prose was revised by hand before it shipped.

The payoff: honesty is the believability

Here is why this matters more for an AI-built product than for any other. When anyone can generate a slick landing page in an afternoon, slick is worthless. What is scarce is a claim that survives inspection. This course can say "a live product that runs on about $27 of AI spend" precisely because it is true and a skeptic can clone the repo and check. On a verifiable product, the honesty is the marketing. The distribution module made this point from the growth side; this module is the same truth from the claims side.

What the gates cannot check

The gates check presence, not quality. A build gate can confirm a feature has a help article and a marketing mention; it cannot tell you the article is good or the claim is well-sourced. Mechanical honesty (does the claim correspond to a real feature) is enforceable. Substantive honesty (is the number real, is the source legitimate) is yours, every time. And the AI will keep offering you the beautiful lie. Keep saying no.

Exercise

Trace one claim to its source. Take any metric, badge, or guarantee in your marketing and follow it to the data and the working feature behind it. If you cannot, kill it or fix it.
Run the audit after your next change. The next time you move a feature between plans, text search every marketing surface for the feature name and the tier phrases, and fix every stale hit before you ship.
Add one coverage gate. Make your build fail if a feature ships without the marketing or docs surface it requires, so that one class of rot cannot happen again.
Write your underclaim line. The all-true sentence you can always fall back to. Use it whenever a tempting claim cannot be sourced.