Delivery validation checklist

Validate the preview before final files move.

Use this checklist when work is delivered for review. It helps both sides confirm what was shown, what needs revision, when validation is recorded, and when final or source files should become available.

Checklist

Delivery validation should be specific, not just "looks good".

A clean validation flow separates review, revision, approval, final-file access, and proof. That makes the end of a freelance project easier to understand later.

Before uploading the preview

Use this before the client sees the delivery.

  • Preview files are clearly named and easy to identify.
  • Preview files show enough work for a real review.
  • Final/source files are separated from preview files.
  • Any watermark, compression, or reduced version is explained.
  • The delivery message tells the client what to inspect.

Before the client validates

Use this during the client review window.

  • The preview matches the agreed scope and deliverables.
  • The client has checked the important details, not only opened the file.
  • Any missing item is written as a revision request.
  • Revision requests are specific and attached to the deal.
  • The client understands validation can unlock final-file access.

Before releasing final files

Use this before final/source/reference assets become available.

  • Client validation or the approved release state is recorded.
  • Final files match the validated preview or agreed revision.
  • Source files are included only if the deal says they are included.
  • External links have the right provider-side permissions.
  • The release action does not conflict with an active dispute or revision.

Before closing the delivery

Use this after validation so the record remains useful.

  • Validation, final-file access, and release state are visible.
  • Important delivery messages are attached to the proof timeline.
  • External links are recorded as provider-controlled when relevant.
  • The client knows where final files or references live.
  • The project can be explained from the Dealokr record later.

Why validation needs a workflow.

Freelance delivery often fails at the very end. The client says a quick "ok", the freelancer sends final files, and then details come back later as if validation never happened. A better process makes review, revision, validation, and final-file access separate steps.

Dealokr is built around that separation. The client can review a preview, request revisions, validate when ready, and then access final or source files according to the deal workflow. The result is calmer for the client and easier to prove for the freelancer.

Use external links carefully.

External tools like Figma, Drive, Dropbox, GitHub, or Vercel are useful for delivery, but they remain controlled by their own permission systems. Dealokr can record the link and gate access in the deal workflow, while the external provider still controls real access.

What should a preview include?

A preview should show enough of the work for the client to make a real validation decision, while keeping final/source files gated when those files carry the project value.

What if the client wants changes?

Ask for a specific revision request and keep it attached to the delivery record. Avoid vague review loops that happen only in scattered messages.

When should final files unlock?

Final files should become available after client validation or an approved release state, according to the deal terms and provider payment workflow.

Delivery without loose ends

Make validation a clear step before final-file release.

Use Dealokr to keep preview delivery, revision requests, client validation, final/source file access, and proof in one shared deal record.