For people who build sites for other people

Six weeks later,
the client says
you broke it.

They changed a plugin, or their new developer did, or nobody did anything and something expired. You have no way to show what you handed over — unless you wrote it down at the time. Record it on delivery day, and any later scan tells you what has changed since, with both dates on it.

Record a handover — $29 →

One site · No account · The record is public and permanent

Handover record independently timestamped

Site: clientsite.com
Recorded: 17 Aug 2026 11:59 UTC
TSA serial: 118070648

Was the certificate valid?✓83 days left

Was anything published by mistake?✓none found

Was a key in the JavaScript?✓none found

Could Google see it?✓indexable

Your client opens one link and checks this against the timestamping authority. Not against you, and not against us.

How it works

Four steps, once per project

Scan on delivery day

Run it when the site goes live, or the day you hand over the keys. Takes about a minute and needs nothing installed.

Send the link with your invoice

The record has its own public address. No login, no account for them to create, nothing for them to install.

It stays true

The record is hashed and timestamped by an independent authority the moment it is made, so neither you nor we can alter it afterwards.

Later, you compare

Accept the record as the agreed baseline. Scan the site again whenever the argument starts, and you get what changed since that date — not since last week. A certificate that expired, a header that disappeared, a key that appeared.

Why the timestamp is the point

A screenshot proves nothing

Anyone can produce a screenshot, or a PDF, or a list of what they checked. The reason those do not settle an argument is that they could have been made at any time, by anyone, saying anything.

Every handover record is hashed as it is collected and submitted to a timestamping authority under RFC 3161 — the same mechanism used for signed documents. The authority countersigns the hash and returns a token. Your client, or their new developer, can verify that token against the authority directly. If we altered a single finding afterwards, the check fails.

That is the whole difference: it is not that we say the site was fine. It is that nobody can change what we wrote, including us.

Being straight about it

What this does not settle

It does not prove the site was good, or that your work was correct, or that a later fault was somebody else's doing. It records what a specific set of checks observed, on one date, from outside.

It does not see anything behind a login, does not read your code, and is not a penetration test. A record with no findings means those named checks found nothing on that day — nothing more.

That is a narrower claim than "the site was fine", and it is narrow on purpose. A record that overstates is worth less in an argument than one that does not, because the first thing anyone disputing it will do is look for the overstatement.

What we found in 12 AI-generated codebases — useful if you are inheriting a site somebody else built with an AI tool, or handing one over.

Record the next one.

Same scan as Preflight, same $29. What changes is who you send it to.