Keeping Marketing Honest
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. The line between the two is the whole job.
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 not the false claim you write. It is the true claim that quietly becomes 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.
The payoff: honesty is the believability moat
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. The honesty is not a constraint on the marketing. On a verifiable product, it is the marketing. The distribution module made this point from the growth side; this module is the same truth from the claims side.
The honest caveat
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.
This is one chapter of the operating playbook.