A sentence on a public page is a statement of fact by the business. If the product cannot produce the record that proves it, the sentence should not ship, however good it sounds.
Most of the copy on a marketplace or a SaaS landing page is written by whoever is closest to the launch, in the hour before it ships. "Trusted by hundreds of families." "Every professional is vetted." "Rated five stars." "Ten years of experience." Those lines feel like marketing, and they get reviewed, if at all, for tone. On the products I build they are reviewed as data, because that is what they are.
A sentence on a public page is a statement of fact made by the business that published it. If the product cannot produce the evidence for that fact on demand, the sentence is a liability with good typography. The rule I hold every page to is short: a claim on the page needs a row behind it.
It helps to read a page the way a regulator or an opposing lawyer would, and ask of each sentence what record would prove it. Some sentences are opinion and need nothing: "we built this because the tools we tried did not fit how agencies actually work". Many are not.
Seen that way, a lot of standard landing-page copy fails immediately on a new product, simply because a new product has no history. That is not a reason to fake one. It is a reason to write copy that describes what the product does rather than how many people it has done it for.
The engineering answer is to stop treating these claims as text. If a page shows a number of reviews, the number comes from the same place the reviews come from, and if there are none, the element is absent rather than showing zero or a placeholder. A rating is computed from real reviews or not drawn at all. A badge that says a professional's licence was checked appears only on a profile where a record of that check exists, and the badge links to what was checked, not to a generic explanation page.
This has a useful side effect: the claim cannot drift out of date. Hand-written copy that was true at launch stays on the page after the fact behind it has changed. A profile badge driven by a field disappears the moment the field is cleared. Where one of my products shows real reviews from its own reviews data, those stay; the rule is not "never show social proof", it is "never show social proof the database did not produce".
It also changes how I review a page. I do not read the copy and judge whether it sounds fair. I search the page for numbers and for a short list of words, and for each hit I ask where the value comes from. If the answer is "someone typed it", it either gets a data source or it goes.
The same principle applies to the part of a page people read most carefully: the price. A price is a claim too, and the claim is incomplete without the terms that change what it costs. If a plan renews automatically, the renewal amount, the billing interval, the fact that it renews and how to cancel all belong next to the price, not on a terms page three links away. A free trial that converts to a paid plan says so where the trial is offered.
Consumer protection rules on automatic renewal in many places require roughly this, and I do not treat it as a legal box to tick at the end. It is a rendering rule. The price component takes the plan, and the plan carries its interval and renewal behaviour, so the disclosure is generated from the same object that produced the number. There is no way to show a price without its terms, because the component does not have a mode for that.
Cancellation follows the same logic. If signing up is a form inside the app, cancelling is a control inside the app, reached in a comparable number of steps. Telling someone to send an email to cancel something they bought with two taps is a design decision, and it is the wrong one.
Terms of use and privacy notices are often copied from somewhere and edited lightly. That is how a product ends up with a privacy notice that does not mention the analytics, payment or email providers it actually sends data to, or terms that name an entity that does not exist. Both are claims, and both can be checked against the system: the list of processors in the notice should match the list of services the product actually calls, and the entity named should be the one that actually operates it.
Where a product uses AI to draft, summarise or suggest, the terms and the notice say so, and say that the output may be wrong. That is not a disclaimer to hide behind; it is an accurate description of the feature, and leaving it out makes the rest of the page less trustworthy.
The friction is real. A page with no invented numbers looks plainer than a competitor's page with a row of logos and a large figure. The trade is that every sentence on it is one I can defend with a record, and nothing on it gets worse when someone checks. For a small company, the cost of a single unprovable claim being challenged is far larger than the conversion it might have bought.
There is also a quieter benefit. Copy written from data is copy that improves as the product does. The first real review appears on the page because it exists. The first completed booking can be counted because it was recorded. The page grows into its claims instead of starting with claims it has to grow into, and the honest version of a new product reads, accurately, as a new product.
The test is mechanical, which is the point. Point at any sentence on the page and ask which record proves it. If the answer is a field, a collection or a dated document, the sentence stays. If the answer is "it sounded right", it does not ship.
Written by Liana Grigory, Entrepreneur and Software Engineer, from work on The Care Royal, Tegula Stone and Unified Savers. Everything above describes decisions actually made on those systems, including the ones that turned out to be wrong.