How to Organize Video Projects You Can Find Again

The failure is rarely dramatic. It is three months later, a clip performed well, and you want to make a follow-up from the same footage — and you cannot find the take. The export is somewhere, the original is nowhere, and the project file has a name like final2new.

Video work generates a lot of files that look similar: many takes, several exports, screenshots, audio recordings, versions. Without a system the folder becomes a pile, and a pile is only searchable by memory.

This is a small system that survives time, and it costs about ten seconds per project.

Decide the naming rule once

The rule should be boring and sortable. Date first, then subject, then version:

2026-11-06-sourdough-timelapse-v02

Why each part earns its place:

• Date first in year-month-day order sorts correctly in every file browser without any special tool. Day-first or month-first formats do not.
• Lowercase with hyphens avoids the space-versus-underscore argument and travels safely between Windows, macOS, Linux servers and web uploads.
• A subject a stranger could understand. Not "clip", not "test", not "edit".
• A version number with two digits, so v10 does not sort before v2.

Apply it to projects, exports and batch folders. Apply it to nothing else; the value comes from it being universal.

One folder per project, three subfolders

Every project gets a folder named with that convention, containing exactly three subfolders:

• raw — camera originals, screen recordings, imported audio. Never edited, never deleted until the project is archived.
• work — the project file, plus anything generated during editing: proxies, transcripts, graphics, music.
• export — finished files, and only finished files.

The discipline that makes this work is that raw is read-only. The moment you trim, rename or move a file inside raw, you have lost the ability to tell the original from the derivative.

If your editor imports by reference rather than copying, this structure matters more, because moving raw breaks the project. Keep the folder in one place and do not reorganise it mid-project.

Version up, never sideways

Replacements are where projects get lost. The habit to build: never edit over a version you might want back, and never use the word final.

Use v01, v02, v03 — and when a reviewer asks for changes, v04 is a copy, not an overwrite. Two rules make this cheap:

• Only version when something external has seen the previous one. Internal saves do not need versions.
• Write one line in a notes file saying what changed in each version. Six weeks later, v07 is meaningless without it.

"final" is the word that ends up on four different files. If you must use a word, use the version number and let the highest one be the current one.

The project file is the artifact

An export is a dead end. The project file is what lets you re-cut, re-caption or re-time the same material for a different platform. Treat it as the thing you are protecting.

Two consequences:

• Save the project somewhere you will still have it. If you edit in the browser, download and keep the project file alongside the export, in the same project folder.
• Keep the material the project depends on. A project file that references a clip you deleted is a file that no longer opens properly.

Backups: the honest minimum

A single copy on a single drive is not a backup, and video files are large enough that people skip this step entirely until they lose something.

The minimum worth doing: keep the working project on your main drive, keep a copy of the export folder on a second drive or cloud location, and keep the raw folder until the project is at least a month old. Exports are small and valuable; raw is large and only sometimes needed again.

If you want the formal version of this, the widely used phrasing is three copies, two kinds of media, one off-site. For a solo creator the practical version is a working drive, an external drive, and one cloud copy of the exports.

Deleting without regret

Space runs out, and the order in which to give it up is fairly consistent:

1. Intermediate renders and proxies. Regenerable, and often the largest files in the folder.
2. Duplicated exports. Keep the highest quality one; the version sent to a client three revisions ago is rarely needed.
3. Raw footage for projects that shipped and are older than a month. Delete only after the export is backed up and the project file is saved.

What not to delete: the project files, the exported masters, and anything you do not have a second copy of.

Handing files to someone else

When a collaborator or client needs the material, send a folder that follows the same convention, and include the notes file. The naming rule is the whole handoff: they can tell which file is newest without opening any of them.

If you are sending an export for review, say which version it is in the filename and in the message. Two people reviewing different versions is the most common way a good edit gets undone.

Search is only as good as the names

Every operating system can search filenames instantly. That only helps if the names contain words you would search for. "clip7" is unfindable; "2026-11-06-sourdough-timelapse-v02" is findable by date, by subject or by version.

The same logic applies inside an editor's project list. A batch of clips named by number is a batch you have to open one at a time. A batch named by subject is a batch you can work through in order.

Start with the next project, not the archive

Reorganising years of old files is a project that never gets finished and produces no videos. Apply the system to the next thing you make. After five projects the habit is set, and the old pile becomes progressively less relevant because everything current is findable.

When the batch workflow in how to batch produce a week of shorts starts producing several projects per week, this structure is what keeps them from turning into a pile.