Case Study 2: Delivering a Finished Piece — One Master, Four Homes

This is a shoot-along-style walkthrough, except the "shoot" is a delivery: we take one finished branded piece and walk it, step by step, out into the world — a high-quality master plus three platform deliverables (YouTube, a 9:16 social cut, and a client file), each captioned, each built to its own spec. Everything here is a constructed teaching example you can follow with your own finished piece and any editor; the settings are typical and every real number should be confirmed against Appendix H before a paid delivery. Where Case Study 1 was an autopsy of a delivery done wrong, this is the delivery done right — do it beside us with a project of your own, and you will have a professional delivery workflow in your hands by the end.

The brief and the constraints

The finished piece is a 90-second product film for a small-batch coffee roaster — a Project 3-style branded piece built around the "product on a table" setup this book keeps returning to. It is done: shot on a controlled tabletop with warm window light and one bounce, cut on a 4K, 24 fps timeline, corrected and matched (Chapter 31), graded to a warm, rich look with deep browns and clean steam highlights (Chapter 32), scored with a licensed track and mixed with dialogue and the hiss-and-pour of an espresso machine, all mastered to about -14 LUFS (Chapter 33). There are two lower thirds (the roaster's name and the origin of the beans) and an end card with the logo and a call to action.

The client's needs, gathered by asking rather than guessing (the §36.3 lesson):

  • Their website — a hero video on the homepage, and, they mention, it "autoplays muted."
  • YouTube — the full film on their channel.
  • Instagram — a vertical cutdown for Reels.
  • A trade show, maybe — "we might loop it on a big screen at a coffee expo next month."
  • The editable master — they don't know they need this yet, but you do, because "can you make a version for X?" is coming.

That is one finished timeline and four different homes, each with its own spec. The temptation — the Case Study 1 mistake — is to export once and hack the rest out of that file. We will do the opposite: build one pristine master and derive every home from it.

FIGURE CS36.7 — The delivery plan: one master, four homes (draw this before you export)

                          ┌──────────────────────────────┐
   LOCKED 4K/24 TIMELINE ►│  MASTER  — ProRes 422 HQ .mov │  full 4K, 24 fps, clean picture,
   (graded, mixed,        │  the authoritative copy       │  no burned-in captions, ~-14 LUFS
    -14 LUFS, captioned)  │  → ARCHIVE (Ch.37)            │  keep this FOREVER
                          └───────────────┬───────────────┘
          ┌───────────────────┬───────────┴───────┬────────────────────┐
          ▼                   ▼                    ▼                    ▼
   ┌─────────────┐    ┌──────────────┐    ┌───────────────┐   ┌──────────────────┐
   │ YOUTUBE     │    │ WEBSITE HERO │    │ INSTAGRAM 9:16│   │ TRADE-SHOW LOOP  │
   │ 16:9 1080p  │    │ 16:9, MUTED  │    │ 1080x1920     │   │ (from the MASTER;│
   │ H.264 .mp4  │    │ autoplay:    │    │ burned-in caps│   │  big screen =    │
   │ + .srt      │    │ BURNED-IN    │    │ safe zones    │   │  give them the   │
   │             │    │ captions     │    │ (Ch.23)       │   │  master itself)  │
   └─────────────┘    └──────────────┘    └───────────────┘   └──────────────────┘
    Every home is ONE generation from the master. Nothing is a copy of a copy.

Notice the plan already solved a trap. The website hero "autoplays muted" — which means a sidecar caption nobody can toggle is useless there, so the website version needs burned-in captions, exactly like the social cut, even though it's horizontal. Reading the brief carefully changed a delivery decision before a single file was exported. That is the whole craft.

The kit: your editor's Deliver settings

The "gear" for a delivery is the export dialog and a little organization. Here is the settings box for the whole job — the master and all four deliverables in one place, so you can see the shape before we build them one at a time.

⚙️ Settings Box: the coffee film's five exports (typical values — verify against Appendix H).

Export Wrapper / codec Resolution / fps Bitrate / quality Audio Captions
Master .mov / ProRes 422 HQ 3840×2160 / 24 codec-determined (high, ~hundreds Mb/s) PCM 48 kHz none (clean) + separate .srt
YouTube .mp4 / H.264 (High) 1920×1080 / 24 constant-quality "high" or ~12–20 Mb/s, 2-pass AAC 48 kHz 320 kb/s sidecar .srt
Website hero .mp4 / H.264 1920×1080 / 24 ~10–16 Mb/s, 2-pass AAC (present, but muted-autoplay) burned-in
Instagram 9:16 .mp4 / H.264 1080×1920 / 24 moderate, generous AAC 48 kHz burned-in
Trade-show (deliver the master .mov) 3840×2160 / 24 — PCM none (big screen, sound on)

Five files, one source. Build the master first; everything else is derived from it or re-rendered from the timeline.

The organization is trivial and it matters: a single /exports/ folder, and names that say what each file is and which version — coffeefilm_MASTER_v03.mov, coffeefilm_youtube1080_v03.mp4, coffeefilm_web-hero-muted_v03.mp4, coffeefilm_ig-9x16_v03.mp4. When the client asks in six months for "that coffee video," you will find the right file in three seconds instead of guessing among final, final2, and FINAL-real. (Naming that survives is Chapter 37; the seed is here.)

In DaVinci Resolve — this book's free reference editor — all of this lives on the Deliver page, where you set each export's format, codec, resolution, and quality, add it to a render queue, and render the queue in one batch. Other editors gather the same fields under a "Media > Export" or "Share" menu and render one at a time. The fields are identical; only the layout differs (see Appendix E for the translations). We describe the decisions generically and let you find the buttons in your own tool.

Phase 1 — Pre-flight: make the timeline truly deliverable

You do not export a piece that is "basically done." You export a piece that is locked, because every export you make from an unlocked timeline is an export you will throw away when the last change comes in. So before any file is rendered, we run the top of the delivery checklist (FIGURE 36.6) across the timeline itself.

FIGURE CS36.8 — Pre-flight on the timeline (before ANY export)
  V2  [ lower third: roaster ][           ][ lower third: origin ][ end card ]
  V1  [ ESTABLISH pour ##### ][ CU steam ###### ][ hands/grind ##### ][ logo ]
  CAP [ "Small-batch, since..." ][ "Beans from..." ][ "Roasted the day..." ][ CTA ]
  A1  [ dialogue / VO ################################################## ]
  A2  [ espresso machine + room ................................ ]
  A3  [ music bed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ]
      ^ picture locked   ^ captions on their own track   ^ mix mastered to -14 LUFS
   CHECK: color final? mix + loudness final? titles spelled right + on long enough?
          clean head/tail (no stray black frames)? audio runs full length? THEN export.

We confirm, line by line: the grade is final and was checked on the best screen available (Chapter 31–32); the mix is mastered to about -14 LUFS with a safe peak ceiling (Chapter 33); the two lower thirds are spelled correctly and held long enough to read; the end card's call to action is legible; there is no stray black frame at the head or tail; and the music and ambience run the full length with no track ending early.

Then we build the thing that will feed every caption decision downstream: a caption track. We type the captions once, on a dedicated subtitle/caption track on the timeline (or auto-generate and then correct every line by hand — names like the bean origin and the roaster will be mangled by auto-transcription, so we fix them). This single caption track is the source for both the sidecar .srt (for YouTube) and the burned-in captions (for the website and Instagram) — we author once and choose the attachment method per export. That is the efficient way to caption a multi-deliverable job: one authored track, many outputs.

With the timeline locked, color final, mix mastered, and captions authored, we are cleared to export. Everything from here is derivation.

Phase 2 — The master: the copy you keep forever

We build the master first, deliberately, because it is the source everything else comes from and the thing that outlives the project.

FIGURE CS36.9 — The MASTER export (build this first)
  ┌─ RENDER: coffeefilm_MASTER_v03 ────────────────────────────┐
  │ FORMAT / WRAPPER   .mov                                    │
  │ CODEC              ProRes 422 HQ    ← near-lossless master │
  │ RESOLUTION         3840 x 2160      ← FULL res (matches TL)│
  │ FRAME RATE         24 fps           ← matches timeline     │
  │ QUALITY            (codec-determined; ~hundreds of Mb/s)   │
  │ AUDIO              PCM (uncompressed), 48 kHz, stereo      │
  │ RANGE              Entire timeline                         │
  │ CAPTIONS           NONE burned in (keep the picture clean) │
  │                    + export the caption track as .srt too  │
  └────────────────────────────────────────────────────────────┘
   Big file — that's correct. This is the negative you print every copy from. ARCHIVE it (Ch.37).

The thinking at each field: ProRes 422 HQ in a .mov because a master should discard almost nothing — it is the pristine source. Full 4K resolution and 24 fps, matched exactly to the timeline, because the master should preserve every pixel and every frame we finished with; we down-res later, per deliverable, from this. Uncompressed PCM audio, because the master's sound should be as clean as its picture. And, critically, no burned-in captions — the master stays clean so it can serve any future home (a re-edit, a different platform, a translated caption set). We do export the caption track alongside as a sidecar .srt, so the authored captions live with the master in text form.

Then we QC the master: open it in a plain player, scrub it, watch a graded section and a motion section, confirm the audio is clean and full-length. This file is about to become the parent of everything else, so any flaw here would propagate — we catch it now. The master passes. We set it aside for archiving (Chapter 37) and move to the deliverables, each derived from this or re-rendered from the timeline.

✂️ In the Edit. Building the master first is the delivery-side expression of "you shoot for the edit." On the shoot you captured extra resolution and bit depth so the edit would have room; here you preserve all of it in the master so future you will have room — to reframe, re-grade, re-caption, or re-deliver to a spec that doesn't exist yet. The master is you shooting for an edit that hasn't been requested. It costs one big file and saves you every future re-do.

Phase 3 — The YouTube deliverable: forgiving, generous, captioned

YouTube is the easy one — forgiving, universal, and it re-encodes everything — so the rule from §36.2 governs: give it a clean, generous file and let it do its thing.

FIGURE CS36.10 — The YOUTUBE 16:9 deliverable
  ┌─ RENDER: coffeefilm_youtube1080_v03 ───────────────────────┐
  │ FORMAT / WRAPPER   .mp4                                    │
  │ CODEC              H.264 (High profile)                    │
  │ RESOLUTION         1920 x 1080     ← 1080p from the 4K src │
  │ FRAME RATE         24 fps          ← matches               │
  │ QUALITY            constant-quality "high" OR ~12–20 Mb/s, │
  │                    2-PASS VBR      ← generous; it re-encodes│
  │ AUDIO              AAC, 48 kHz, stereo, 320 kb/s           │
  │ RANGE              Entire timeline                         │
  │ CAPTIONS           export sidecar .srt (upload with file)  │
  └────────────────────────────────────────────────────────────┘

The choices: 1080p because it's the sensible web delivery here (we could deliver 4K — YouTube supports it — but 1080p at a generous bitrate looks excellent and uploads faster; if the client wanted a showcase-quality 4K listing we'd deliver 3840×2160 at several times the bitrate). H.264 .mp4 for universal playback. Generous bitrate, 2-pass, because the platform will re-encode and can only work from the quality we hand it. AAC at 320 kb/s so the mix isn't re-crushed. And captions as a sidecar .srt — YouTube supports and rewards them, they're toggleable and translatable, and search engines read them. We upload the .mp4 and the .srt together.

QC: watch the exported .mp4 start to finish on a big screen — does the grade hold, does the motion stay smooth, is the loudness right? Then a spot-check on a phone. It looks like the timeline. Ship it.

Phase 4 — The Instagram 9:16 deliverable: sound-off, safe zones, burned-in

Now the shape changes. The source is 16:9; Instagram Reels wants 9:16, watched sound-off on a phone. This is a reframing job (Chapter 23's §23.5) plus a caption-strategy change.

FIGURE CS36.11 — Reframing 16:9 → 9:16 for the product shot (keep the product in the safe zone)

   SOURCE 16:9 (product left-third, steam rising right):
   ┌───────────────────────────────────┐
   │        ☕steam                     │
   │   [ CUP ]        (negative space)  │        9:16 CROP WINDOW slides to keep
   │        hands                       │   ───► the CUP + steam centered in the tall
   └───────────────────────────────────┘        frame; caption sits in the lower-center
                                                 SAFE ZONE, clear of the interface (Ch.23).
   RESULT 9:16 (1080x1920):
   ┌───────────┐
   │  ☕steam   │  ← keep the hero (cup + steam) centered & inside the safe zone
   │ [ CUP ]   │
   │  hands    │
   │▓"Small-   │  ← BURNED-IN caption, lower-center safe zone, big and legible
   │  batch"▓  │
   └───────────┘

The thinking: we crop-and-reframe the 16:9 into a 9:16 window that keeps the product — the cup and the steam, the hero of a product film — centered and inside the safe zone, keyframing the crop to follow the action where the shot moves (the pour, the hands). We rebuild the lower thirds for the tall frame if needed, and we set the captions to burned-in, lower-center, large and high-contrast, because this is sound-off territory where a toggleable caption would never be seen. We derive this from the master (or, better, re-render from the timeline so the reframe and captions are first-generation).

FIGURE CS36.12 — The INSTAGRAM 9:16 deliverable
  ┌─ RENDER: coffeefilm_ig-9x16_v03 ───────────────────────────┐
  │ FORMAT / WRAPPER   .mp4                                    │
  │ CODEC              H.264                                   │
  │ RESOLUTION         1080 x 1920      ← vertical (9:16)      │
  │ FRAME RATE         24 fps           ← matches              │
  │ QUALITY            generous, constant-quality "high"       │
  │ AUDIO              AAC, 48 kHz, stereo (~-14 LUFS mix)     │
  │ RANGE              Entire timeline (or a 30–60s cutdown)   │
  │ CAPTIONS           BURNED-IN, safe-zone, high contrast     │
  └────────────────────────────────────────────────────────────┘

QC — and this one is judged on an actual phone, in a vertical feed if possible: is the cup always in frame and inside the safe zone? Are the burned-in captions legible and clear of where the interface sits? Does it hook in the first two seconds with the sound off? A social cut that fails the sound-off phone test fails, full stop, no matter how good it looked on the desktop timeline. Ours holds. Ship it.

Phase 5 — The website hero and the client handoff

Two homes remain, and both are about reading the brief.

The website hero autoplays muted — so, like the social cut, it needs burned-in captions (a muted autoplay video with toggle-only captions is a silent, wordless loop). It stays 16:9 and 1080p, H.264 .mp4, generous bitrate. It's essentially the YouTube export with one change — captions burned in instead of sidecar — which is exactly why authoring the caption track once in Phase 1 pays off: same source, different attachment.

The trade-show big screen is the interesting call. A big screen with the sound on is the one place quality matters most and compression shows most — so we don't hand them a compressed web file at all. We give them the master .mov (or a fresh high-bitrate 4K export from the timeline). This is why we built and kept the master: the "maybe a big screen" request, which would have been a disaster to serve from a starved web file (Case Study 1's fate), is trivial to serve from a pristine source.

Finally, the handoff itself, which is part of delivery:

  • Each file is named clearly and versioned so it survives (Chapter 37).
  • We deliver the right file to the right home — the YouTube .mp4 + .srt for the channel, the muted-caption hero for the site, the vertical for Instagram, the master for the expo — with a one-line note saying what each file is and its spec.
  • We keep and archive the master (Chapter 37) before moving on, because the next request — "can you also make a 15-second teaser?" — will be served from it in minutes.

The whole delivery, in one pass

Step back and see the shape of what we did, because it is the professional workflow, and it is not complicated:

  1. Lock the timeline and run pre-flight (color, mix, loudness, titles, clean heads/tails).
  2. Author captions once on a caption track.
  3. Build the master first — pristine, clean, archived.
  4. Derive each deliverable to its own spec, from the master or the timeline — never from another deliverable.
  5. Match each home's spec: YouTube (generous, sidecar captions), muted website hero (burned-in), 9:16 social (reframed, burned-in, safe zones), big screen (the master itself).
  6. QC every file on the screens its audience uses.
  7. Name, hand off, and archive.

Five files, one source, no generation loss, every home captioned and correct, and a master in the vault for every request that comes next. Compare it to Case Study 1's ninety minutes of clicking Export and going home. The difference isn't talent or gear — both editors had those. The difference is that delivery here was treated as a stage with a craft, run on a checklist instead of on memory. That is the entire lesson, and you now have the workflow.

Six months later: the requests the master makes trivial

The real test of a delivery workflow is not the day you finish — it is every day after, when the requests you did not anticipate arrive. Because we built and kept a clean master, watch how each one, which would have meant a painful re-do in the Case Study 1 world, becomes fifteen minutes of easy work.

  • "Can you make a 15-second teaser for our email newsletter?" You open the master (or the project), pull the fifteen strongest seconds, and export a small .mp4 from a pristine source. No hunting for the original, no re-compressing a compressed file. Fifteen minutes.
  • "We got into a regional TV spot — they need a broadcast file." The broadcaster sends a spec document. You take the master (near-lossless, full quality) as your source, conform it to the broadcaster's exact frame rate and codec, remaster the audio to their loudness standard (~-23 LUFS, not the -14 you delivered for web), and add their required sidecar caption format. This is real work — but it is possible, and it starts from a pristine source. Had you kept only the compressed web file, you could not have delivered a broadcast-quality file at all; you would have had to re-export from a project that may no longer open cleanly, or tell the client no.
  • "Can we get it with Spanish subtitles?" You take the caption track you authored in Phase 1, translate it, and deliver a second sidecar .vtt. The master needed no captions burned in, so it accepts a new language set without a single frame re-rendered. Ten minutes.
  • "The website is being redesigned — we need a square 1:1 version now." You reframe from the master or timeline, keep the product in the safe center, burn in captions, export. One generation from the source, not a copy of a copy. Twenty minutes.

Every one of these requests is served from the master, and every one is cheap because the master exists, is clean, and is derived-from rather than photocopied. This is the quiet, compounding payoff of the discipline: the work you did once, correctly, keeps paying you back every time the project has a second life. The editor who shipped only a compressed file six months ago is now re-doing work, apologizing for quality, or turning down the broadcast spot. You are billing fifteen minutes and looking like a professional who thinks ahead — because, at delivery, you did.

A note on the muted-autoplay trap

One detail from this walkthrough deserves its own emphasis, because it catches even experienced editors and it is pure spec-reading. A muted-autoplay video — the website hero, and increasingly many in-feed placements — plays with no sound and no user interaction. That single fact cascades through your delivery: a sidecar caption the viewer would toggle on is useless (there is no viewer clicking anything), so captions must be burned in; and, more subtly, if your edit relied on narration or dialogue to carry meaning, a muted viewer gets none of it, so the piece must tell its story visually or with burned-in text. The lesson generalizes: a viewing context is part of the delivery spec, and sometimes it reaches back and changes the edit itself. "Where and how will this be watched?" is not a delivery afterthought — it is a question that belongs in the brief, before the first frame is shot, so that a muted hero is cut to work muted rather than discovered to fail muted at export. That is "fix it in pre, not in post" applied to delivery.

Discussion questions

  1. We built the master first, before any deliverable. What would we have risked by building it last, or not at all? How does building it first change the way you think about all the other exports?
  2. The "autoplays muted" detail in the brief changed the website hero's captions from sidecar to burned-in. What other small brief details can silently change a delivery decision? How do you make sure you catch them?
  3. We authored captions once and output them two ways (sidecar and burned-in). Why is authoring-once-output-many more robust than captioning each deliverable separately? Where else in delivery does that principle apply?
  4. For the trade-show big screen we delivered the master, not a web file. Articulate the rule for when a destination deserves the master versus a compressed deliverable.
  5. The 9:16 cut was judged on a phone, in a feed, sound-off. Why is the screen and context you QC on part of the delivery spec, not an afterthought? Give an example where a file that "looked fine" on a desktop would fail this test.
  6. Every deliverable here was one generation from the source. Describe the shortcut that would have added generations, why it's tempting under deadline, and the exact discipline that prevents it.

Your turn: deliver one of your projects to four homes

Take a finished (or near-finished) piece of your own — ideally one of your portfolio projects — and run this exact workflow.

The brief you'll invent: imagine a client who wants the piece for (a) YouTube, (b) a muted-autoplay website hero, (c) Instagram Reels, and (d) "maybe a big screen." Then deliver all four, plus a master.

Do this, in order:

  1. Lock and pre-flight your timeline against FIGURE 36.6's top section. Fix anything not final. Author a corrected caption track.
  2. Build the master first — ProRes/DNxHR .mov if you can, high-bitrate H.264 if storage is tight — full res, matched frame rate, clean picture. QC it. Set it aside to archive.
  3. Derive the four deliverables, each to its own spec, each from the master or the timeline: YouTube (generous, sidecar .srt), muted hero (burned-in), 9:16 Reel (reframed, safe zones, burned-in), big screen (the master itself).
  4. QC every file on the screen its audience uses — the vertical one on an actual phone.
  5. Name and organize every file so you could find it in a year, and write the one-line delivery note for each.

When you're done, you will have taken one timeline out into the world four different correct ways — which is, precisely, the delivery craft this chapter teaches and the exact thing the Production Checkpoint asks you to do for all three of your projects. Do it once here, deliberately, and it becomes the way you finish every project for the rest of your career.

Key takeaways

  • Delivery is a workflow, not a button: lock → caption once → master first → derive each home → QC every file → name and archive. Run it every time and delivery stops being scary.
  • Build the master first. It is the pristine source every deliverable is derived from and the thing that outlives the project; keeping it clean (no burned-in captions, full res) lets it serve any future home.
  • Read the brief for hidden spec changes. "Autoplays muted" silently turned the website hero's captions from sidecar to burned-in — a delivery decision made by reading, before any file was exported.
  • Match each home to its own spec: generous and sidecar-captioned for YouTube; burned-in for muted-autoplay and sound-off social; reframed with safe zones for 9:16 (Chapter 23); the master itself for a quality-critical big screen.
  • Author captions once, output them many ways. One corrected caption track feeds both the sidecar .srt and the burned-in versions — efficient and consistent.
  • QC on the screen the audience uses. The 9:16 cut is judged on a phone in a sound-off feed; the master on a big screen. The context is part of the spec.
  • Every deliverable is one generation from the source. Deriving from the master or the timeline — never from another deliverable — is what keeps four files looking as good as the one timeline they came from.