Every freelancer has a version of this folder:
logo_draft.ai
logo_draft_v2.ai
logo_draft_v2_client_notes.ai
logo_v3_FINAL.ai
logo_v3_FINAL_actually_final.ai
logo_v3_FINAL_actually_final_2.ai
It's a running joke in creative work — until it's the reason a client uses the wrong file in a print run, or asks you (again) which one they're supposed to be reviewing. Filename versioning isn't a personality quirk. It's a system with no error correction, and errors compound silently until they surface at the worst possible time.
The hidden cost isn't storage — it's ambiguity
Filenames are free. Ambiguity isn't. Every time a client has to guess which file is current, one of three things happens:
- They guess right, but you'll never know for certain they did.
- They guess wrong, and the mistake surfaces downstream — often after it's expensive to fix.
- They stop guessing and email you, turning your inbox into the actual version-control system.
None of these are acceptable outcomes for something a database constraint could solve outright.
What "one released version" actually means
The fix isn't a better naming convention — conventions rely on humans remembering to follow them under deadline pressure, which is exactly when they break down. The fix is making "which version is current" a fact enforced by the system, not a fact someone has to maintain by hand.
Concretely, that means:
- Every upload creates a new, immutable version — nothing gets overwritten.
- Exactly one version can be marked "released" at any time.
- The client-facing link only ever shows that one version, full stop.
When "current" is enforced this way, an entire category of mistakes becomes structurally impossible rather than merely discouraged.
Notes belong to the version, not to an email
The other quiet cost of filename versioning is that context gets separated from content. "Fixed the kerning per your note" lives in an email; the file itself has no idea what changed or why. Six months later, when you're reviewing your own work, you're archaeologically reconstructing decisions from a Sent folder.
Attaching release notes directly to each version — not as a separate email, but as metadata on the version itself — means the what and the why travel together permanently. That's not a nice-to-have; it's the difference between a project history you can actually use and one you have to reconstruct from memory.
Rethinking "storage"
If you take one thing from this: stop thinking of your deliverables folder as storage and start thinking of it as a record. Storage is about not losing things. A record is about being able to answer, unambiguously, months later: what did we ship, when, and did the client sign off on it. Filenames can do the first job. They were never designed to do the second.