Project Organisation That Survives Fifteen Revisions

Every project is organised on the first day. Folders get made, clips get imported, everything is where it should be. The scheme is never tested then, because nothing has gone wrong yet.

It gets tested six weeks later, when a change comes back on a video you have stopped thinking about, and you open a folder containing final.mp4, final_v2.mp4, FINAL_client.mp4 and a project file that reports eleven missing media items. At that moment you are not looking for a file — you are trying to reconstruct which one you actually delivered. This guide covers the folder scheme, the naming rule and the version discipline that make that moment uneventful, and the media handling that stops the reconstruction from being necessary at all.

What Actually Breaks

Three things fail, and none of them is untidiness.

Ambiguity about what is current. Two files that could both be the delivered version is not a naming problem; it is a missing rule about which one is authoritative. Every "which one did we send?" conversation traces back to this.

Broken links. Media that has moved since the project was saved. The files exist, the project cannot find them, and reconnecting a hundred items by hand is an afternoon.

Missing dependencies. The project opens, the timeline is intact, and the title font is not installed on this machine. The edit is fine; the deliverable is not, and the substitution is silent.

An organisational scheme is only worth what it does about these three. Everything else is housekeeping.

A Folder Scheme

The structure matters less than being identical across every project, because that is what lets you find something in a project you have never opened.

The numeric prefixes exist so the folders sort in workflow order rather than alphabetically, which means the folder you need next is always the one below the one you are in. It reads as fussy until you have used it on a second project, at which point navigating an unfamiliar job takes no thought.

The important line is between 05_exports and 06_delivery. Exports are everything you rendered. Delivery is the subset that left the building. Keeping them separate is what makes "which one did the client see" answerable without checking your sent mail.

Name for Sorting, Not for Description

Descriptive names feel helpful and sort badly. client-approved-cut.mp4 tells you something and puts itself between autosave and draft in the listing.

Three components handle nearly everything.

A date, written year first. 2026-03-14 sorts chronologically in every file browser on every system, with no convention to remember. Written any other way it does not.

A short project slug. Consistent across every file in the project, so a stray export found in a downloads folder is still identifiable.

A zero-padded number where sequence matters. shot_03 and shot_12 sort correctly; shot_3 and shot_12 do not.

2026-03-14_northgate-launch_v04.mp4
2026-03-18_northgate-launch_v05-client.mp4
2026-03-18_northgate-launch_v05-client_captions.srt

The caption file inherits the video's exact name, which is the detail that stops the wrong subtitle track being attached to the wrong cut later. That principle scales badly if it is invented per project, which is why it is worth fixing once — the same reasoning applied to language variants is set out in managing subtitles in eight languages.

One Current Version, and It Says So

The rule is short: exactly one file may be the current version, and its name identifies it without anyone having to remember.

Numbered versions increment and are never reused. A version that went to a client gets marked as such in the name, because that is the fact you will need in three weeks. And the word final does not appear anywhere, ever — not from superstition, but because it is a claim about the future that has never once been true, and the second file called final is where the confusion starts.

Autosaves are not versions. Let the editor manage them in their own folder and do not treat them as history — they are a crash recovery mechanism, and reading them as a record of decisions will mislead you.

Media Is Part of the Project

A project file does not contain your footage; it contains references to where the footage was. Everything about media handling follows from that.

Decide the location before you import, not after. Moving 01_source after linking breaks every reference in the timeline, and reconnecting is work with no creative return. If the project must be relocated, move the entire project folder as one unit so the internal structure is preserved.

Keep source media read-only once it lands. Renaming a clip after it has been used, or re-transcoding it in place, produces the same broken link with none of the warning. If a file needs a better name, do it on the way in.

Where the footage is large, work with proxies and keep them inside the project rather than in an application-wide cache, so archiving the folder archives everything needed to reopen it.

Copy in the fonts and graphics the project depends on. This is the failure that appears last and hurts most: a project reopened two years later renders with a substituted typeface, and nothing in the interface announces it.

Setting Up in Five Minutes

The track layout step is the one that pays across the whole project rather than at the end, and it is covered properly in timeline editing fundamentals. Where several videos come out of one shoot, these conventions have to hold across all of them simultaneously — a harder case set out in batching a week's output in a single sitting.

Two Complications Worth Planning For

Cloud-synced folders. Putting an active project inside a folder that syncs to cloud storage causes two distinct problems. The sync client rewrites files while your editor has them open, which is a genuine corruption risk on project files, and it uploads every render and every cache file, which is slow and expensive for no benefit. Work on local storage and sync the archive when the job is finished, or exclude the cache and export folders from syncing explicitly.

More than one person. As soon as a second editor touches a project, the scheme needs one addition: it must be obvious who has it. A shared project file with no ownership convention produces two divergent edits that cannot be merged, because timelines do not merge. Either use your editor's collaboration features properly, or agree that the project file has one owner at a time and everyone else works from exports. The middle position, where people take copies and mean to reconcile later, is the one that loses work.

Next Steps

Open the oldest project you might realistically be asked to change and try to answer two questions in under a minute: which file did the client receive, and will this project open with everything it needs? If either takes longer than that, the scheme you used has already failed and the next project should not repeat it.

Then build the template folder. Duplicating a correct structure is the only version of this that survives contact with a deadline — discipline applied per project does not. The rest of the workflow material sits under editing craft and workflow.