How to send a master to a client for approval

You finished the master. Now comes the part nobody mastered: getting it in front of the client, collecting feedback, and walking away with a clear "yes." Most engineers still do this with a file-transfer link and email — and it quietly costs them audio quality, clean revision notes, and a paper trail. This is how to do it properly.

Why the WeTransfer + email workflow fails

It moves bytes, but a deliverable is more than bytes. The usual flow breaks down in five predictable ways:

• Lossy review. You email an MP3 "so it's small," so the client approves something that isn't the master you'll deliver.
• Vague feedback. "Turn the vocal up around the second chorus" — no timecode, no version, a round-trip to even find the spot.
• No sign-off. Nothing records that they approved this version. "I never said that was final" has no answer.
• Expiring links. The download dies in a week; the client comes back in a month and it's gone.
• Unprotected masters. A raw link means anyone with the URL has your client's unreleased master.

What a clean review-to-delivery flow looks like

Four steps, one link, no accounts for the client:

1. Share a lossless review link

Send a single link. The client plays the master losslessly in the browser — no login, no download, no MP3. They judge the actual audio you made, which is the only thing an approval should ever be based on. (If you're curious how lossy encoding changes a master, see true peak and loudness metering.)

2. Collect feedback on the waveform

Good feedback is precise. When the client pins a comment to an exact point on the waveform, "the de-ess at 2:14" replaces "somewhere in the bridge." Revision notes become a list of timecodes instead of a paragraph you have to decode.

3. Get the sign-off on the record

The single most undervalued step. When the client approves a specific version, capture it: which master, who approved it, and when. That record is what turns a future dispute into a non-event — and it marks the moment responsibility for the master transfers from you to them.

A sign-off isn't bureaucracy. It's the line between "the version we agreed on" and an open-ended revision loop.

4. Deliver the master, protected

Once it's approved, deliver the final files tied to the approved version — not a raw link anyone can forward. "Protected" should mean four concrete things:

• Password-protected — the unreleased master isn't reachable by URL alone.
• Revocable — you can kill the link the moment a deal changes or a file goes out by mistake.
• Download-tracked — you can see whether the client actually grabbed the files, so "I never got them" is checkable.
• Persistent — it doesn't silently expire in a week and strand the client a month later.

Handling revisions without losing the thread

Revisions are where the email workflow really frays. Upload each new version against the same track so the client can A/B v1, v2 and v3 at the same timecode and hear exactly what changed — ideally loudness-matched so they judge the change, not the level. Open feedback carries forward to the new version, so nothing gets lost between rounds. They approve the version that's actually final.

The short version

Stop sending masters as email attachments. Send a lossless review link, take feedback on the waveform, record the approval of a specific version, and deliver protected. Your client hears the real thing, your revisions stay precise, and you keep a sign-off you can point to.