Most privacy policies are fiction. Not malicious fiction, usually: a template gets pasted in at launch, the site's actual tracking changes over the years, and nobody ever reconciles the two. The result is a legal document describing a website that does not exist.
We build the policy and the code as one artifact, and we hold a simple standard: a privacy policy that contradicts what the site actually does is a factual error, the same class of defect as a wrong phone number. It gets fixed with the same urgency. That standard sounds obvious. It is also rare, because meeting it requires the people writing the policy and the people writing the code to be the same team, working in the same repository, on the same commit history.
The policy is typed data
On Creative Maintenance Solutions, a Belzona applicator in Virginia, the privacy policy is not a document pasted into a page. It is a typed data file in the same content layer as the products and services: 20 titled sections plus a five-paragraph plain-English summary up top, rendered by the same components as everything else on the site. The summary exists because a policy nobody can read protects nobody; the 20 sections exist because the law is genuinely that wide.
The terms of use are built the same way, 27 sections covering arbitration, liability caps, and intellectual property. And the pattern repeats across the portfolio: Polymer Nation carries 21 privacy sections, Salyers Construction 17, IMS 17, SearchRadar 16. Where the business demands more, the code goes further still; Salyers enforces its age gate on both the client and the server rather than trusting a checkbox. Legal pages live in version control next to the code they describe, and they change through the same review as everything else.
That location is the point. When the policy is a data file in the repository, the commit that adds a tracker and the commit that discloses it can be the same commit. When the policy lives in some page builder on the other side of a login, they never are, and the drift begins the week after launch.
The render tree enforces the promises
The policy says no analytics or marketing trackers load before consent. Here is what makes that sentence true: the tracker components literally render nothing until their consent category is granted. Google Analytics, Meta Pixel, Vercel Analytics, the identity-resolution script; each is a component that returns null pre-consent. No script tag, no network request, no cookie. The claim is not enforced by good intentions. It is enforced by the render tree.
The policy says Global Privacy Control is honored as a binding opt-out. In the code, a GPC signal forces the marketing category off regardless of any stored preference, and the banner tells the visitor it did so. Even when analytics is consented to, it runs with IP anonymization switched on in the config.
The policy discloses identity resolution in a clearly headed section, flagged for careful reading, as sale and sharing under the state privacy laws. In the code, that script has exactly one sanctioned mount point, and it loads only when the vendor is configured, marketing consent is granted, and the visitor is geolocated in the United States. The geolocation itself is engineered conservatively: an edge middleware stamps the visitor's country into a cookie, the gate requires an exact match, and when the cookie is missing it fails closed to blocked rather than defaulting on.
Withdrawal works too. Reject after having accepted, and the code actively expires the analytics and pixel cookies that were already set instead of just stopping new ones. Consent records are versioned and timestamped. Accept all and Reject all get equal visual weight, by written design decision, because a consent flow that nudges is a consent flow that lies.
What honest disclosure can afford to say
Because the disclosures describe real behavior, they can afford to be thorough. The Creative Maintenance policy covers, among other things:
- GDPR and UK GDPR, CCPA and CPRA, the Texas TDPSA, Virginia's consumer data law, and other state statutes
- A data-retention schedule and breach-notification commitments
- COPPA, automated decision-making, and defensive coverage of wiretap-style claims
- A dedicated, clearly headed section on identity resolution
- An embedded accessibility statement
That is a legal surface many funded startups launch without, sitting on a local industrial contractor's website. The client did not ask for it by name. It ships because we consider it part of what a finished website is.
Why we hold this line
Partly risk. Regulators and plaintiffs' firms now read privacy policies against network logs, and a policy that promised opt-in consent while the pixels fired anyway is evidence, not protection. The template defense does not exist.
Mostly, though, it is the same rule that governs everything else we ship: never fabricate. A star rating without reviews behind it is fabrication, and so is a policy paragraph describing consent behavior the site does not have. The document carries the client's name. Every sentence in it is a claim we have to be able to back, and the only reliable way to back it is to write the sentence and the code together.
The test is simple and worth borrowing: open your policy next to your site's network tab. Load the page fresh, grant nothing, and watch what fires. If the two disagree, one of them is wrong, and it is never the network tab.
