Stale by Tuesday: Why Your Product Claims Rot Faster Than Your Code

Think about how much machinery stands guard over your code. Tests run on every commit. CI blocks the merge when they fail. A deploy gate lints, type-checks, and smoke-tests before anything reaches a user. If a function starts lying about what it does, something goes red within minutes, somewhere, and keeps going red until a human deals with it.

Now think about how much machinery stands guard over the sentences you've written about your code. The pricing page. The feature list. The FAQ. The privacy policy. For most teams — ours included, until recently — the answer is: nothing. No test asserts that the copy is true. No build fails when it stops being true. A claim can be wrong for six months and the only alarm that ever sounds is a confused customer, a refund request, or nothing at all — just a quiet trickle of people who believed a sentence, got something else, and didn't bother telling you.

Last week we audited our own product pages and found four false claims. Nobody had lied. Every one of them was true when written. That's the interesting part, and it's what this essay is about: the mechanism that turns true sentences into false ones without anyone touching them.

Four Claims, One Mechanism

Here's what we found, in ascending order of discomfort.

One. Our Developer Labs page told visitors to “create an account to persist your work and share projects via link with your team.” The Labs have no account system. No save. No share links. Not a broken version of those features — their complete absence, verifiable in about ninety seconds of looking at the code. Anyone who built something substantial in a Lab believing it was being saved would have lost it on tab close, exactly as the page promised they wouldn't.

Two. Our privacy policy described the same phantom: “Developer Labs projects are saved only if you choose to sign in.” A privacy policy describing a data flow that does not exist is a special category of wrong, because the entire value of that document is that it is literal. It now says what's true — nothing is stored, anywhere, which happens to be the stronger privacy claim — but it said the false thing for months.

Three. PromptUI's in-app upsell offered “10 more generations for just $19.” The live price grants five. Ten was the previous tier, retired when the pricing changed — the marketing page got updated, the blog got updated, and one panel inside the app kept quoting the dead offer. That's a 2× overstatement of what a buyer receives, sitting on the exact screen where they decide to buy.

Four. PicSift declared itself Windows-only in exactly one place: a JSON-LD structured data block, invisible to every human reader. The visible page said “activates on 1 PC,” which implies Windows the way a wink implies a fact. A Mac user could read the entire page carefully and buy a $29 license for software that cannot run on their machine.

Four different pages, four different kinds of claim — a feature description, a legal document, a price, a system requirement. But run the histories back and it's one story every time: the product moved, and the sentence didn't. The Labs shipped without accounts after the copy was drafted ahead of a roadmap that changed. The pricing changed in the checkout system, and one surface out of three got missed. The platform commitment narrowed, and the structured data got updated by whoever knew, while the prose stayed generic. Nobody wrote a false sentence. Time falsified true ones.

Why the Asymmetry Exists

The reason claims rot faster than code isn't that people care less about them. It's structural, and it's worth stating precisely, because the fix falls out of the statement.

Code is load-bearing at runtime. Claims are load-bearing at purchase time. When code is wrong, the program misbehaves now, in front of instruments built to notice: exceptions, failed assertions, error rates, alerts. When a claim is wrong, nothing in your system misbehaves at all. The misbehavior happens in someone else's head — a customer forms a false belief, makes a decision on it, and the consequence lands days later as a refund, a support ticket, or silent churn, none of which arrives labeled “the FAQ lied.” The feedback loop isn't slow. For most claims, there is no loop.

Code has one source of truth. Claims have copies. The price lives in the checkout system once, and in prose — the pricing page, the in-app upsell, the FAQ, the comparison table, three old blog posts. Every copy is a chance to miss one when it changes, and our PromptUI miss was exactly that: two surfaces updated, one forgotten. Prose has no imports. Nothing tells you who's referencing the fact you just changed.

And code changes announce themselves. Claims fail by staying still. A diff is an event; someone reviews it. A sentence going stale is a non-event by definition — the file wasn't touched. The most dangerous claims on your site are the ones untouched the longest, which is precisely backwards from code, where untouched usually means stable.

The Compounding Problem: Claims About the Absence of Things

One class of claim deserves special fear: statements about what your product doesn't do. “No tracking.” “Works offline.” “No account required.” “Your data never leaves your machine.”

These are the best claims in your marketing — specific, differentiating, trust-building — and they are uniquely fragile, because they can be falsified by anyone adding anything. A feature claim breaks only if someone removes the feature. An absence claim breaks when an engineer adds an analytics snippet, a session store, a cloud sync — each a reasonable Tuesday-afternoon change made by someone who has never read the privacy policy and has no reason to know it just became fiction. Our Labs claims were this in reverse: the copy promised a presence that never shipped. Either direction, the lesson is the same. The claims most worth making are the ones most worth re-verifying, because they're standing bets against the future of your own codebase.

The Cheap Fix: Treat Claims Like Certificates

The instinct after an audit like ours is a resolution: be more careful. Resolutions don't survive contact with a Tuesday. The fix that works is the one that doesn't depend on anyone remembering, and the model for it is sitting in your infrastructure already: the TLS certificate. Nobody “stays vigilant” about certificate expiry. The certificate has a date, the date comes, a system checks, a renewal runs. Claims can work the same way, in three escalating tiers of effort:

Tier one: inventory. One file, listing every load-bearing claim on your site — each price, each feature promise, each absence statement, each system requirement — and where each one appears. This costs an afternoon, and it converts “our copy” from a vague territory into a checkable list. Ours surfaced the pattern immediately: the four false claims were all facts that lived in multiple places, and every miss was a copy that wasn't the canonical one.

Tier two: a calendar. Claims get re-verified on a schedule, like certificates get renewed. Quarterly is enough for most; a pricing surface deserves better. The verifying is mechanical — open the page, open the product, check that the sentence is still true. Twenty minutes a quarter, and it would have caught all four of ours inside three months instead of letting one run for six.

Tier three: assertions. Some claims can be tested by machines, and those should be. If the checkout system says the Starter pack grants five credits, a test can read the marketing page and fail when it says ten. If the privacy policy says nothing is stored, a test can grep the Labs for localStorage and fail the day someone adds it. We now run checks like these on the claims that burned us — not because tests are free, but because the claims they guard are the ones a human demonstrably walked past for months.

Why Bother, Beyond Hygiene

There's a colder business case than tidiness. Small software companies live on trust they can't buy. A big vendor survives a wrong sentence on a pricing page; the customer shrugs, because the relationship rests on a hundred other things. When you're small, the copy is the relationship — it's most of what a prospect will ever know about you before paying. A false claim discovered after purchase doesn't read as an oversight at that scale. It reads as the shape of things to come, and it's the most expensive impression you can make, because the refund costs you a customer and the story costs you the people they'd have told.

The inversion is also true, and it's the cheerful part. Verified claims compound the same way stale ones corrode. A site where every sentence survives checking — where the limits are stated as plainly as the features, where the price on the page is the price at checkout, every time — builds the kind of trust that turns one purchase into a catalog customer. We wrote a whole fit guide leading with our products' limits on that theory. This essay is the maintenance schedule behind the same bet: honesty isn't a launch-day property. It has a shelf life, and it needs renewing.

Your code already has a guardian. Give your sentences one, and you'll stop finding out from customers what your own website says.