Six months into your brand, you have three logo files. Eighteen months in, you have fourteen. By year three, you have a folder labeled "logo-archive" with thirty-eight files and you're not sure which one was the final agreed version after the refresh that almost shipped last spring.
This isn't disorganization. It's the natural accumulation of versions every brand produces over time. The fix isn't to be more careful when saving files. The fix is a versioning system that handles the accumulation deliberately, so you always know which version is current and what each variant exists for.
Here's the system that works for solo founders through teams of 30.
The difference between versioning and naming
Naming conventions answer: what is this file?
Versioning answers: which iteration of this file is current, and what's the history?
These are different problems with different solutions. A file can have a perfect name and still be impossible to track through versions. Or you can have rigorous versioning without consistent naming and still find what you need. They work together but solve different things. This post is about the versioning layer.
The three states every brand asset lives in
Useful versioning treats every brand asset as occupying one of three states at any given time:
Active. The version currently in use. This is what gets pulled when someone needs the asset. There is exactly one active version per asset type at any given moment.
Pending. A version that's being prepared but not yet adopted. The refresh you're working on. The variant you're testing. The new size you're producing. Multiple pending versions can exist; they're not "live" yet.
Archive. Versions that were previously active but have been replaced. These exist for historical reference: investor materials that referenced old versions, the brand history page, the occasional need to understand what came before.
Most file systems don't enforce these states. Founders need to enforce them via folder structure or a small set of conventions.
The folder structure that enforces the states
For each major asset category, three folders:
logos/
├── active/ (the current versions, what people pull when they need a logo)
├── pending/ (work in progress. Refresh designs, variants under review)
└── archive/ (previous active versions, dated and kept for reference)The same pattern applies to other categories: colors/active/, typography/active/, templates/active/, and so on.
When you make a change:
- Work happens in
pending/ - When pending is approved and ready to go live, it's moved into
active/ - The file currently in
active/gets dated and moved toarchive/
This three-step ritual prevents the most common versioning failure: working in active, accidentally overwriting good versions, and losing the previous state forever.
The "active" folder rule
One rule that does most of the work: the active folder never contains multiple versions of the same asset. One logo SVG, not three "final" candidates. One favicon. One primary email banner.
If multiple options exist for the same thing, exactly zero of them are active. They're all in pending until the decision is made, then exactly one becomes active.
This rule eliminates the "which file is current?" question. The active folder is the answer. If you're looking somewhere else, you're looking at history or unfinished work.
What goes in the archive
Every file leaving active goes to archive with a date prefix:
logos/archive/
├── 2024-03-logo-primary.svg (logo from initial launch)
├── 2025-08-logo-primary.svg (logo after the 18-month refresh)
├── 2026-02-logo-primary.svg (current active version was promoted Feb 2026)
└── ...The date prefix is when the file was archived (i.e., when it stopped being active). Reading the archive top-to-bottom gives you the version history.
Don't try to archive working files. Don't archive every minor revision. Only archive what was once "active". The canonical version that was in use. Drafts, working files, and abandoned experiments don't belong in archive; they belong in pending until you delete them.
The pending folder rule
Pending is where work happens. Multiple versions, drafts, experiments, refreshes-in-progress. All fine. But pending has a single discipline: every file in pending should have either a clear next step or a removal date.
The next-step rule prevents pending from becoming a graveyard. If you're not going to do anything with a file in the next month, it should either go to archive (if it represents a meaningful decision) or be deleted (if it represents an abandoned experiment).
Schedule a 30-minute "pending cleanup" once a quarter. Walk through pending, ask each file "is this going somewhere?" and act accordingly. Without this rhythm, pending grows indefinitely and loses its utility as a working space.
The metadata layer
For every active asset, maintain one line of metadata somewhere your team can find. The metadata answers: when did this version become active, what changed from the previous, who approved.
A simple format:
asset: logos/active/logo-primary.svg
became_active: 2026-02-15
replaced: logos/archive/2025-08-logo-primary.svg
change_summary: Tightened coral dot geometry; reduced wordmark tracking 0.02em
approved_by: [founder name]Store this in a brand-changelog.md file at the root of your brand asset folder. It's a one-line entry per change. Over years, it becomes the brand's version history. Useful for onboarding new team members, evaluating brand drift, and reconstructing why decisions were made.
The "rollback" question
Real versioning includes the ability to roll back. If a new version doesn't work, you should be able to revert to the previous version without scrambling.
The archive folder provides this naturally: the previous active version is just the most recent archived file. Rolling back is moving it from archive back to active and demoting the current active to archive.
Three rules for rollback:
- Don't delete archived files for at least 12 months. Rollback decisions sometimes happen months after a change.
- Test rollback occasionally. Once a year, simulate rolling back. Make sure your archive is actually retrievable, not corrupted or lost.
- Document why you rolled back. A rollback always gets a changelog entry: what didn't work, what's reverting, when.
The cloud vs. git question
Two practical approaches to the versioning structure above:
Cloud storage (Google Drive, Dropbox, Notion). Folders enforce the structure. Cloud's built-in version history adds a safety layer beyond your manual archives. Works for solo founders and small teams. Easy to share with non-technical contributors.
Git repository. The active/pending/archive structure becomes folders in a repo. Git's commit history replaces the manual changelog. Branches handle experiments. Pull requests handle approval flows. This is heavyweight for solo founders but ideal for teams with technical members and many contributors.
Pick the lighter approach unless the team size justifies the heavier one. Most companies under 20 people are better served by cloud storage + the manual changelog. Companies past 20 with active brand operations benefit from git.
The five-minute weekly habit
The system works if it's maintained. The minimum maintenance habit:
Once a week, five minutes. Open the brand asset folder. Look at active and pending. Two questions:
- Anything in active that should have been moved to archive (because it's no longer current)?
- Anything in pending that's done or should be abandoned?
Act on whatever you find. Close the folder. Five minutes.
This weekly check is what prevents drift. Without it, the system you set up on day one decays into the chaos you were trying to avoid. With it, the asset library stays clean indefinitely.
Brand asset versioning is one of those operational details that feels boring until you need it. The hour you spend setting it up. And the five minutes per week maintaining it. Saves you the future weekend you'd otherwise spend reconstructing what your brand actually looks like and which version is the one to use.
Your brand kit, ready in 10 minutes.
Five quick taps. Free preview before you pay.
Start building free →