Getting your project files back

A year after the videos were made, something changes. A number on screen, a date, a member of staff who has left, a logo, a claim you are no longer allowed to make. All you need is thirty seconds swapped out of a video that is otherwise fine.

So you go back to whoever made it. And either they still have it and it takes an afternoon, or they do not, or they have moved on, or they have it in a form nobody else can open, and the honest answer becomes that it is cheaper to film the whole thing again.

This is the least discussed part of paying for video and one of the more expensive ones.

Why does nobody ask until it is too late?

Because the finished video looks like the whole deliverable, and for the first few months it is.

The file plays, it is on your channel, the job is done. Nothing in that experience suggests there is a second thing you should have received, and no supplier is going to raise it unprompted, because raising it means committing to a standard of organisation that is genuinely more work.

Then time passes and the video becomes an asset rather than a post. Assets get edited. The moment you want to edit one is the moment you find out what you actually own, and it is frequently also a moment when a relationship has cooled, which is precisely the wrong time to be asking a favour.

What is a project file, and why is it not enough on its own?

A project file is not a video. It is a list of instructions: use this clip from here to here, put that graphic on top, apply these settings, fade the music down at this point.

Which means it is useless without the things it is pointing at. Hand somebody a project file alone and they will open a timeline full of red rectangles saying media offline. It knows what should be in each slot and has nothing to put there.

This is why can I have the project file is the wrong question, asked in good faith, and why it so often produces a technically honest yes that turns out to be worth nothing.

What should you actually ask for?

A package, not a file. Six things, and each of them is protecting against a specific failure.

1. The project file, in a format another editor can open. Not everybody uses the same software. Ask what it was edited in and whether an exchange format can be provided alongside it, and accept that an exchange can lose some effects and needs checking. 2. The media it points at, in the folder structure it expects. Original footage, audio, anything downloaded. Moving files after the fact is what breaks projects. 3. The fonts. A project opened on a machine without them substitutes something else, and every title in the video quietly changes. 4. The graphics in editable form. A lower third baked into the picture is not an editable graphic. The layered original is. 5. The music and its licences, with the paperwork, saved under your own account. 6. The exports, including a text-free master: the finished cut with no subtitles or titles on it, which is what makes a second language version or a re-caption possible without a rebuild.

Then one thing that is not an item: a folder structure a stranger can read. Names that describe contents, dates in a consistent order, no folder called final final. Everything above is worth considerably less if finding it requires the person who made it.

Does editable mean the same thing to everyone?

No, and this is where politely worded requests fall apart.

To one supplier, editable means the layered file with every element still separate. To another it means an export with a transparent background, which is a picture that cannot be changed. Both will say yes to the same question, and you will not find out which one you got until somebody tries to change the wording.

So ask in specifics rather than in categories. Can the text in the titles be retyped. Can the colour of the lower third be changed. Can the logo be swapped for a new one. Can the music be replaced without redoing the mix. Those four questions produce four unambiguous answers, and the answers tell you what kind of supplier you have long before anything goes wrong.

When should you ask?

At the start, in the agreement, before the first invoice, and never at the end.

At the start it is a scoping conversation between two reasonable people. At the end it is a request for extra work from somebody who has already been paid, which turns a process question into a negotiation and sometimes into a grievance.

It is worth being fair about why. Preparing a handover properly is real work. Files have to be gathered, tidied, checked on a second machine and delivered, and a supplier who has quoted for editing has not quoted for that. Agreeing it at the beginning lets it be part of what you are buying. Springing it at the end asks somebody to do a day's work for nothing, and you will usually get what an unpaid day produces.

In this studio the split is deliberate. What leaves with you is everything the work is made of: the finished cuts and a text-free master of each, the footage we shot, the fonts, and every licence bought for the job, taken out in your name where the licensor allows. It sits on a platform you can reach rather than a drive only we can open, the retention period is written down at the start, and what you are licensed or assigned to do with each piece is written down beside it, because holding a file is not the same as holding the right to use what is in it.

What stays with us is the editable timeline, the layered project a new editor would open to change a shot in an afternoon. That is our craft, the how rather than the what, and keeping it is not the lock-in this piece warns about: you hold the footage and the masters, so another editor can continue your library without ever seeing our timeline. The titles still come with you, as alpha-channel clips you can lay over anything and move at will; retyping them is the editable project, which is the craft. The file is the convenience. The asset is the thing, and the asset is yours.

There is one case where we push the other way. If what you are making is paid, gated, or a course, content that is itself the product and will be re-cut for years, then the source is part of the asset and worth holding, and we say so before the work starts, the moment we see it, or the moment you ask, whichever comes first. The editable project is then arranged with its own terms, as part of the scope. That is a recommendation for that kind of work, not how every partnership runs: for a channel that keeps moving you will almost never open a year-old timeline, and paying to tidy one you will not use is the wrong trade.

What if you edit your own videos?

Then you are the supplier, and every word above applies to you with nobody to ask.

Run the six-item check on your own last project. Move the folder somewhere else and open it there. What goes red is what you would have lost had the drive failed. Save the fonts beside the project, keep each licence with the video it belongs to, and name the folder for what is in it.

None of that is for a future supplier. It is for you in a year, who will have forgotten all of it and will be, for practical purposes, a stranger to your own timeline.

If you do work with somebody, ask them one thing this week: if you were unavailable for a month, could another editor finish or amend this. Their answer is more informative than any contract clause, because it is answered instinctively and it describes how the work is actually organised.