Durvy
Retour au blog
3 min de lecture

How to organise client files so you can find anything in 30 seconds

A folder structure, a naming convention, and a retention rule. Boring, and it saves an hour a week plus the occasional disaster.

Every freelancer eventually loses time to the same thing: hunting for the signed contract, the final logo file, the version the client actually approved, or the receipt for a purchase made eight months ago. The fix is unglamorous and takes an hour to set up once.

One structure, used for every client

The specific shape matters less than using the same one every time. A structure that works for most freelance work:

  • Client folder, named exactly as the client is named everywhere else
  • 01 Admin — contract, proposal, purchase orders, supplier forms
  • 02 Brief — the brief, research, reference material, meeting notes
  • 03 Working — everything in progress, versioned
  • 04 Delivered — final files, exactly as sent, never edited afterwards
  • 05 Invoices and receipts — copies, even if the originals live in your invoicing tool

The critical distinction is between working and delivered. Delivered is a record of what the client actually received, and it never changes. Working is where the mess lives. Collapsing the two is how you end up unable to say what you sent.

Naming that sorts correctly

  • Start with a date in reverse order, 2026-09-14, so files sort chronologically by default.
  • Then the client or project code, then a short description.
  • No spaces, no special characters, because they break in some tools and some clouds.
  • Version with numbers, not words. v01, v02, v03. Never final, final2, final-actual.

Example: 2026-09-14acmehomepage_v03.fig

Sorting is the whole point. A folder that sorts into a chronological narrative is one you can read at a glance three years later.

Version control, lightweight

Full version control is overkill for most freelance work, but two habits get most of the benefit:

  • Increment the version on every send to the client, never overwrite one you have sent.
  • Keep a one line log in the project folder: version, date sent, what changed, what the client said. Two minutes per round, and it is what saves you when someone says they never approved something.

Retention and backups

  • Keep financial records for the period your jurisdiction requires, typically five to seven years.
  • Keep delivered work indefinitely where storage allows. Old clients return, and being able to produce the original files two years later is a small miracle from their perspective.
  • Three copies, two media, one offsite is the classic rule, and cloud sync plus one external drive satisfies it.
  • Test a restore once a year. A backup you have never restored from is a hypothesis.

Cloud sync alone is not a backup. A deleted or corrupted file syncs its deletion everywhere in seconds, which is exactly why version history and a separate copy matter.

Access and offboarding

  • Never keep the only copy of a client asset. When a project ends, hand over everything they own.
  • Remove yourself from client systems you no longer need access to. Lingering admin access is a liability with no upside.
  • Keep credentials in a password manager, never in a document in the project folder.

Where the structured records live instead

Not everything belongs in a folder. Invoices, expenses, hours, and client contact history are records with state, and they belong in tools that maintain that state rather than in files. What you keep in folders is documents: contracts, briefs, working files, deliverables.

The rule of thumb: if it has a status that changes over time, it belongs in a system. If it is a fixed artefact, it belongs in a folder with a good name.

TL;DR

  • One folder structure for every client, with a hard split between working and delivered.
  • Date first naming in reverse order, numeric versions, no spaces.
  • Keep a one line version log per client round. It settles approval disputes.
  • Three copies, two media, one offsite, and test a restore annually. Cloud sync alone is not a backup.