What Should Creators Do Before Sending Files to Clients?

What Should Creators Do Before Sending Files to Clients?

The moment a file leaves your hands, you lose a little bit of control over it. A designer emails over a set of mockups. A developer shares a working demo. A photographer sends a gallery of proofs. A copywriter attaches a first draft. In each case, the creator has just handed a client something valuable and, if things go sideways later, something that's suddenly hard to prove was theirs to begin with.

This isn't a hypothetical worry. Scope disputes, late payments, unauthorized reuse, and "who actually made this first" arguments are some of the most common friction points between creators and clients. And they almost always come down to the same missing piece: nobody can say, with certainty, what existed and when.

The gap between "I made this" and "I can prove I made this"

Most creators keep original files as part of their proof of project history. Preserve those files and their metadata, while recognising that file dates can change during copying, conversion or migration. Timestamping adds an external reference for an exact saved version.

If a client later claims they came up with the concept, or a competitor lifts unreleased work and publishes it first, "I have the file" isn't a defense. What holds up is independent, third-party evidence that the file existed in its current form at a specific point in time evidence you didn't generate yourself and can't be accused of backdating.

Certelo’s browser flow creates a cryptographic fingerprint of the file and anchors it to a public, tamper-evident record. Nobody including the creator can quietly alter that record after the fact.

The five-minute habit that prevents months of arguments

Before a single file goes out the door, it's worth building in a short, repeatable step: generate a hash of the file, timestamp it, and keep the resulting record somewhere safe. This isn't about distrust of any particular client it's a professional habit, the same way a contractor photographs a job site before starting work.

Here's roughly what that looks like in practice:

• Hash the file. A SHA-256 file hashing process converts the document, image, code repository, or audio file into a unique fingerprint. Change even one pixel or one line of text, and the fingerprint changes completely.

• Timestamp the fingerprint, not the file. The fingerprint not the actual content gets anchored to a blockchain ledger. This means creators never have to upload sensitive, unreleased, or confidential work to a third party just to prove it exists.

• Keep the certificate. The resulting timestamp certificate becomes portable proof: an independently verifiable record showing that specific file, in that specific state, existed at that specific moment.

• Then send the file. Only after this record exists does the file go to the client.

A timestamp records the fingerprint when it is registered. Creating it later cannot establish an earlier date. Preserve delivery records separately to show when and how the file was shared.

Why this matters differently across creative disciplines

A designer can timestamp a concept board before sharing it, then keep the original with client feedback and revision history. The proof supports existence of that file version; it does not identify who designed it.

A developer can timestamp a source snapshot or demo build before sharing it. Keep contribution records and agreements separately: a timestamp does not establish code authorship, ownership or a right to use the software.

A photographer sending low-res proofs before the final sale is establishing that the images, at full resolution, existed before the client ever saw them, closing off any claim that the client "already had" the shots.

A writer or copywriter can preserve a first draft and its timestamp before revisions. The proof helps identify the saved version; correspondence and project history provide context about who wrote or changed it.

Across disciplines, the narrow benefit is independently checkable evidence that a matching file existed by the recorded time. Authorship, ownership, authenticity of the underlying statements and legal outcomes remain separate questions.

What this looks like if a dispute actually happens

If a client disputes which version was delivered, compare the preserved file and timestamp with delivery messages and attachments. The blockchain reference can be inspected independently, and a reviewer with the file can compare its hash. The timestamp alone does not prove delivery or resolve the dispute.

If someone publishes a file without permission, a timestamp may contribute to a chronology of the saved versions. It does not establish ownership, infringement or permission to use the work, and it guarantees no legal outcome.

Making it part of the workflow, not an afterthought

The creators who benefit most from this aren't the ones who timestamp files reactively, after a relationship has already turned adversarial. They're the ones who treat it as a standard pre-delivery step, the same way they'd back up a project file or save a version history. It costs a few minutes. It requires no special technical knowledge. And it means that if a dispute ever does arise, the creator isn't scrambling to reconstruct a timeline from memory they already have it, dated and verifiable.

Certelo gives creators an independent, blockchain-based way to timestamp and verify their work before it ever leaves their hands quiet, routine proof that's there if they ever need it.