Counsel-Grade Legal Pages for a Small App

Every app needs a privacy policy, and almost every small app gets one the same way: a generator, a template, or a copy of the last one, adjusted.

The problem with all three is not that they are badly written. It is that they are assertions about your software, and nobody has checked them.

“We encrypt data in transit.” Do you, on every leg? “We do not share data with third parties.” What about the analytics library? “You may request deletion of your account.” Can they, today, without contacting you?

Each of those is a factual claim. Published, it is a representation to your users and to two app stores.

What we did instead

Rather than trying to make every statement true before launch — which would have held the release for months — we marked each statement that had not been verified against the code, and counted them.

38 statements were unconfirmed.

That number is the useful artefact, and it changed the conversation in three ways.

It made the risk countable. “The privacy policy might not be accurate” is a feeling. “There are 38 specific claims nobody has verified, here they are” is a work item with an end.

It made the review cheap. Handing a lawyer a policy and asking them to check it is an open-ended engagement. Handing them 38 marked statements, each with a note about what is uncertain, is a bounded one.

It made the pages honest in the meantime. The drafts carry a banner saying so, and they are excluded from search indexing until the claims are confirmed. A page that says “this is a draft under review” is a defensible state. A page that confidently asserts unverified things is not.

The translation multiplier

We added the same pages in a second language, and the unconfirmed count went from 38 to 75.

That is arithmetically obvious and organisationally surprising: the same facts are now unconfirmed twice, in two documents, and a reviewer has to see both. It is the correct way to count, and it makes a real point about translated legal content — a translation is not a copy, it is a second document making the same claims, and it inherits every uncertainty.

Two decisions we would make again:

Every translated page names the English as authoritative. Otherwise you have created a second source of truth that can diverge, and neither is clearly the one that governs. This is the standard convenience-translation clause and it exists for exactly this reason.

Counsel reviews both together, not sequentially. Reviewing the English and then the translation invites the translation to be treated as a formality, which is how a divergence survives.

★ Insight ------------------------------------- Marking uncertainty rather than resolving it is the move worth stealing, and it generalises past legal pages. Any document making claims — a security questionnaire, a capability statement, a tender response — can carry an internal marker on each unverified assertion. The count becomes a metric, the review becomes bounded, and the document stops silently accumulating statements nobody owns. The alternative is the usual one: everything reads as equally confident, and nobody can tell which parts were checked. -------------------------------------------------

The gate that did not cover the new pages

Worth including because it is the kind of thing that undoes the whole exercise.

We have a tool that refuses to release while any page still carries unconfirmed claims. It held a hardcoded list of pages to check.

When the translated pages were added, they were not on the list. A translated page could have quietly lost its draft banner or its exclusion from search and gone live while the English equivalent was still held back — precisely the ungated surface the tool exists to prevent.

The fix was to derive the list rather than maintain it. The general rule: a gate with a hardcoded inventory covers what existed when it was written, and the thing you add next is by definition not on it.

The draft state is a legitimate place to be

One objection worth answering: does publishing a page marked as a draft not look unprofessional?

Less than the alternative, and the alternative is what most apps do — publish a confident document that asserts unverified things, because a draft banner feels embarrassing.

A page that says it is under review is honest about a state every small business has been in. A page that confidently claims end-to-end encryption the system does not provide is a misrepresentation, and it is one a technically competent user can disprove in a minute.

The banner is also a forcing function. A draft that has carried a banner for four months is visibly overdue in a way that a finished-looking page never is.

What to do if you have template legal pages now

Four steps, none requiring a lawyer to start.

1. Read your own policy and mark every claim you cannot personally verify. Not “might be wrong” — “I do not know whether this is true”. Most people find between twenty and fifty.

2. Check the three that are almost always wrong. Whether every connection is actually encrypted end to end, including the leg between your server and its origin. Whether the analytics or crash-reporting library shares data you said you do not share. Whether deletion is genuinely available without contacting you — both stores now require a route that works from outside the app.

3. Fix what is cheap, mark what is not. Some claims are easier to make true than to verify. Others need counsel.

4. Only then get a review. With the marked list, which is a fraction of the cost of an open-ended read.

The three claims that are usually wrong

From doing this on our own pages, the statements that most often fail verification are the same three, and they are worth checking first because each is cheap to test.

“All data is encrypted in transit.” Almost always true of the leg a user can see, and frequently not true of every internal hop — between a load balancer and an origin server, or between your application and a third-party service. If any leg is plain, the claim is false as written, and it is the kind of falsity that is trivially demonstrable.

“We do not share your data with third parties.” Then the app includes analytics, crash reporting, a mapping SDK, or an advertising identifier. Each of those is a third party receiving data. The claim usually needs to become “we do not sell your data” plus a named list.

“You can delete your account at any time.” Check that the route exists, works today, and is reachable from outside the app — both stores now require that, on the reasoning that somebody who has uninstalled must still be able to ask.

Those three take under an hour to check and they account for most of what a reviewer would find.

Why this matters more than it used to

Both app stores now treat the privacy declaration as a binding statement, checked automatically against observable behaviour. A mismatch is a policy violation found after release rather than a rejection before it.

And the privacy policy is the document a regulator or a customer reads first when something goes wrong — not because it is the most important, but because it is the one you published.

---

Awesome Apps is an app developer in Sydney building and publishing iOS and Android apps for Australian businesses. General information about app compliance, not legal advice.