Freelance Retoucher File Handoff Without a Shared Dropbox

What a shared folder actually grants

A folder invite is an all-or-nothing grant. Once a freelance retoucher has "can view" or "can edit" on a shared Dropbox or Drive folder, they can see everything in it — past jobs, other clients' files, anything a teammate dropped in the same space to save a step. There's no concept of "this job only." And the access doesn't expire on its own; someone has to go back into folder settings and remove a specific person, which competes for attention against everything else on a studio's plate the week a job wraps.

The result is a gap between when a job ends and when access to it actually ends. Neither side is malicious — most freelance retouchers never open a folder again after delivering their work — but the gap exists whether anyone uses it or not, and it grows every time a studio takes on another freelancer without a process to close the last one out.

It also grows in a second, quieter way: folders get reused. A studio that set up "Retouchers" once, and just kept dropping new jobs into subfolders inside it, has effectively been re-inviting every freelancer who ever worked with them to every job since — because nobody wants to be the person who audits folder permissions instead of shooting the next booking. The permission model of a general-purpose sync folder was built to make sharing easy, and it does. It was never built to make access end.

The freelance retoucher file handoff that scopes and expires

A freelance retoucher file handoff that actually holds up needs three properties, none of which a general-purpose file-sync folder was built to provide:

• Scoped to the job. The retoucher sees the frames they were hired to work on — not the folder those frames happen to live in.
• Revocable in one action. Ending access is a single click when the job wraps, not a settings page someone has to remember to visit.
• No account required. A freelancer working with five different studios shouldn't need five different logins to receive five different jobs.

A share link created with retoucher-level access does this by design: it's generated for one job, it opens straight to the frames in question, and revoking it ends the retoucher's access on their very next request — not on their next login, because there isn't one to wait for.

Why storage writes should stay admin-only

Scoping access solves who can see files. It doesn't solve who can write them. A freelancer with edit permission on a shared folder can, technically, overwrite a master file, delete a version, or move something into the wrong project — not out of malice, just because a shared folder makes no distinction between "review this" and "you now own this storage location."

The cleaner boundary is a server-side write path: the retoucher's session gets checked and authorized before any file lands in permanent storage, rather than the retoucher holding write credentials to the bucket itself. That's a different shape of trust than "here's a folder, don't touch anything else in it" — it doesn't rely on the retoucher's good judgment at all, because the write path itself won't accept a request outside the scope of the job.

In Appruva, storage writes stay admin-only for exactly this reason — delivery goes through a server function that authorizes the caller's session, so a revoked or scoped link can't be used to write anywhere the job didn't call for. A retoucher who still has an open browser tab after their access is revoked can't push a file through it; the next request is checked against current permissions, not the permissions that existed when the tab was opened.

Inside the panel: what the retoucher actually touches

Once a retoucher has scoped access to a job, the next question is what they do with it. Appruva's Photoshop panel is where that work happens, and everything below is built and has been run end to end in a real Photoshop install — this is what it does today, not a roadmap.

• It identifies which frame the open document is — an XMP stamp first, then filename matching, then it asks — so a retoucher working across a batch never has to eyeball which file is which.
• The client's notes sit in the panel itself, numbered to match the badges the client saw, rather than living in a separate email or spreadsheet the retoucher has to cross-reference.
• Markup lands on the file as a real vector layer sized to the document — not a screenshot pasted into a layer, which is the habit this replaces and the reason that pasted-in markup never lines up at full resolution.
• A crop guide drawn on the document crops the canvas in one click, ticks the note, and re-maps the rest of the markup so it still lands correctly.
• When a note has a reference image attached — "match this skin tone" — it opens beside the document as its own file, so the retoucher can actually sample from it.
• Ticking a note off happens in the panel as the work gets done, and when the job is ready, Deliver exports by the studio's recipe, uploads, and closes out the ticked notes.

None of this requires the retoucher to have a studio account, and none of it requires them to hold write access to anything beyond the job they were sent.

Version control without a folder full of 'final_v3'

A shared folder handoff usually produces its own naming problem on top of the access problem: shoot_final.jpg, shoot_final_v2.jpg, shoot_final_v2_retouch.jpg, each one a guess at which is current rather than a record of it. That's a familiar failure mode — the same one that makes finding the current edit hard even when access isn't an issue at all.

A version stack tied to the job, rather than a folder of similarly-named files, answers two questions a folder can't: which round did the client actually approve, and what changed between that round and the one before it. When a freelancer's delivery lands as a new version in that stack instead of a new file in a folder, both questions stay answerable after the freelancer is gone and the access is revoked.

A handoff checklist for the next freelance job

None of the above requires new software discipline from the retoucher — it requires the studio to set up the job correctly once. Before sending the next batch to a freelancer:

1. Create access scoped to that job specifically, not a standing folder the freelancer will reuse for the next one too.
2. Confirm the freelancer doesn't need an account to open it — if they do, that's a sign the access is broader than the job.
3. Set a date to revoke access, and put it somewhere it will actually be seen — a job-close checklist, not a mental note.
4. Check that delivered files land as a new version tied to the job, not a new file in a shared location.

Studios that already run reviews through Appruva get most of this by default: retoucher access is a link scoped to one job, revoking it is one action, and delivery writes go through an authorized session rather than the freelancer's own storage credentials.