Client Says “That’s Not What I Asked For”? Prove Them Wrong.

Yes. On every plan except Essential, and on any capture paid with a SnapPack credit, the capture is anchored to the Bitcoin blockchain through OpenTimestamps, which proves the deliverable existed in that exact state no later than the time of the block it was anchored in. A blockchain anchor cannot be backdated.

ProofSnap captures a full-page screenshot, the complete page HTML, the DOM text and the page metadata, then hashes every file with SHA-256 and records those hashes in a manifest signed with an RSA key. Changing any file breaks its hash and the signature, so tampering is detectable.

Yes. ProofSnap works with any web page you can open in Chrome or Edge, including Figma designs, Google Docs, staging URLs, Vercel previews, Netlify deploys and WordPress admin panels. If you can see it in the browser, ProofSnap can capture it.

An evidence package documents the capture process and lets anyone re-run the checks offline. That is what a court is looking for when it asks whether a record is what you say it is. Rule 901(b)(9) of the Federal Rules of Evidence gives as an example of evidence that satisfies the authentication requirement "Evidence describing a process or system and showing that it produces an accurate result." Small claims courts apply their own state rules and decide the question themselves, but a package of this kind gives a judge far more to work with than a plain screenshot.

A plain screenshot or PDF can be edited in any image editor and carries no proof of when it was made. ProofSnap adds a SHA-256 hash of every file, a digital signature over the manifest, a blockchain timestamp and a full chain of custody log, and it ships verification scripts so anyone can check the package offline.

Yes. The Professional plan carries 200 captures a month, enough to document every milestone, deliverable and client approval across a retainer engagement. Each capture adds a timestamped entry to your record of the work.

Seal the deliverable first, before you send anything. The client who is about to dispute the work is also the one most likely to change or take down the page you delivered, and once it is gone you are arguing from memory. Then send the written reminder, which in a US small claims context is your demand letter in everything but name: it should name the invoice, the amount, the original due date and a firm new date, and it should ask whether the client disputes any part of the work. Keep a capture of the reminder too. If this ends up in front of a judge, the sequence matters as much as the content, because a dated capture taken before the dispute started is worth more than one taken after it.

A court wants to see three things in order. What was agreed, what you delivered, and when. Build the file as four exhibits that cover them, because the approval deserves one of its own. First the brief or statement of work, captured on the day it was agreed, which fixes the scope before anyone renegotiates it. Second the approval, whatever form it took, because a client who accepted the work in writing has a harder time calling it defective later. Third the deliverable itself, captured live at the URL where it was handed over, which is the exhibit a screenshot cannot replace. Fourth the invoice and the reminders, showing that you asked for the money and when you asked. Each capture carries its own SHA-256 hash and its own timestamp, so the four read as a dated sequence rather than a folder of screenshots, and a judge can check every one of them without taking your word for anything.

Then the argument is no longer about whether you delivered, it is about what the statement of work said before the client started adding to it. Capture the SOW or the brief on the day it was agreed, and capture it again each time the scope moves. What you end up with is a dated series showing the original scope, each change and who asked for it, which is what turns an unbillable extra into a billable one. That is a separate job from proving delivery, and it has its own guide: how to prove scope creep by locking the original SOW.

It is worth more, not less. Without a signed document the case rests on what each side did: that the client asked for the work, that you delivered it, and that they took the benefit. Courts recognize an implied contract on exactly that pattern, and the pattern has to be shown rather than asserted. A dated capture of the brief in a chat thread, of the deliverable as it went live, and of the message where the client used what you built is the record that shows it. Capture those while the client is still friendly, because once the relationship sours the thread gets deleted and the page comes down.

A single ZIP holding 11 to 15 files, depending on the plan: the full-page screenshot, the page HTML, the extracted on-screen text, a metadata file with the URL and the HTTPS status, a human-readable evidence PDF, a forensic log, a chain of custody log, a manifest listing the SHA-256 hash of every file, an RSA-4096 signature over that manifest, the public key to check it, and the verification scripts. Professional and above add the OpenTimestamps blockchain proof. You can hand the whole ZIP to a client, a mediator or a court, and none of them has to take your word for any of it: the scripts re-run the checks offline.

Sign-off is rarely a signed document. It is a line in a chat thread, a comment on a staging build, a reply to an invoice, or the plain fact that the client put the work live and kept using it. Capture the approval the day it arrives, in the place it arrived: the Slack message, the email in webmail, the Figma comment, the project board card that moved to Done. Each capture carries its own SHA-256 hash and its own timestamp, so the approval sits in the record at a fixed date rather than in your memory of the conversation. Then capture the deliverable as it went live. A client who approved on Tuesday and disputed on Friday is arguing against two dated captures, not against your account of what was said.