How to Organize Client Assets

By Mason Goulding · Aug 28, 2025 Updated Aug 28, 2025

A principle-first approach to managing logistics — and liability.

Why Asset Organization Matters

Every project begins with a flood of files. Logos in four formats, headshots named final-FINAL.jpg, a half-complete spreadsheet of brand colors, PDFs from the last agency, Word docs with “approved copy,” and a WeTransfer link that expires tomorrow. If you run client work, you’ve lived this chaos.

Disorganized assets don’t just waste time — they introduce risk. Liability hides in the mess.

The problem isn’t clutter; it’s cost. Disorganization burns billable hours, creates rework, and undermines trust. Ship the wrong logo? Use an outdated disclaimer? That’s not inefficiency — that’s exposure. Asset organization isn’t a “nice-to-have.” It’s operational hygiene that protects margin, momentum, and your reputation.

Principles Before Tools

Tools multiply whatever system you already have — good or bad. Before picking platforms, set rules you can enforce with any stack.

Single source of truth: every asset has one canonical home.
Clear hierarchy: folder names and file names reflect use, not whim.
Version control: no “final2-rev3-REALFINAL.ai”. History is tracked, not guessed.
Accessibility: collaborators can get what they need without pinging you.
Security: sensitive docs aren’t shared as open links in random threads.

With principles locked, your tooling can actually enforce the system instead of fighting it.

Folder Architecture That Works

Boring wins. Here’s the baseline structure we use at Maelstrom Web Services. It’s deliberate, predictable, and scales without surprises:


/client-name/
  /01-contracts/
  /02-brand/
    logo/
    colors/
    typography/
  /03-content/
    copy/
    media/
  /04-design/
  /05-development/
  /99-archive/

Numbers keep sort order consistent. Leading zeros prevent “10” from jumping ahead of “2”. Contracts always live in 01-contracts. Active work stays out of 99-archive. No hunting. No guesswork.

File Naming Conventions

Random names create bottlenecks — especially when multiple vendors touch the same brand. Use a convention you can teach in 60 seconds and enforce with linting:

Pattern: client_assettype_detail_version.ext
Example: acme-logo-horizontal-color-v02.ai

Verbose? Sure. But search, filter, and sort all work instantly. And the right file is obvious.

Git, Or Your Margin Will Disappear

If your files aren’t versioned, you’re gambling with time, trust, and liability. Git is non-negotiable. It gives you atomic history, reversible changes, precise blame, and repeatable releases. No “which version is safe?” Slack threads.

How we actually use Git

Branches = safety rails: feature work never pollutes main; reviews happen in pull requests.
Conventional commits: human-readable history (feat:, fix:, chore:) and auto-generated changelogs.
Tags + releases: what shipped, when, and why — immortalized.
Pre-commit hooks: formatting, linting, image budgets, and secret scans before mistakes land in history.

Learn Git fast (pick one and ship)

Local Assets: What Doesn’t Belong in Your Repo

Not everything should live in Git. Some assets are too large, too sensitive, or too volatile. Treat your repo like a cockpit: only the controls that matter to ship should be inside. Everything else is cargo — store it safely, reference it clearly.

Keep these out of Git (and where to put them)

Licensed fonts & stock packs: respect licenses; use a private bucket (S3/Cloudflare R2). Reference from /docs/assets-catalog.md.
Gigantic binaries: raw video, layered PSD/AI, uncompressed TIFF — use cloud storage or Git LFS only when necessary (and track cost).
PII and contracts: never in the repo. Keep in a secure drive with role-based access; commit a stub doc pointing to the canonical location.
Secrets: no .env in Git — ever. Use host-level env vars or a secrets manager. Commit .env.example only.
Build artifacts & caches: .cache, node_modules, dist, OS cruft — ignore via .gitignore.

Pattern that scales


/assets/
  /images/           # optimized, production-ready
  /icons/            # SVG, minified
  /fonts/            # only if license allows bundling
/docs/
  assets-catalog.md  # links to large/off-repo assets and licenses
.gitignore
.env.example

The README documents where off-repo assets live (bucket name, path, retention). New collaborators onboard without DM’ing you for the font zip.

Build a System That Expands Instead of Breaking

Growth kills fragile systems. The goal is boring predictability: add a page, a section, a locale — nothing snaps. That requires a few architectural choices up front.

1) Namespaces, not junk drawers


/src/
  /content/      # markdown, copy, data
    /blog/
    /locations/
    /services/
  /layouts/
  /partials/
  /styles/
  /scripts/

Each namespace has one job. Content doesn’t leak into layouts. Scripts don’t leak into styles. When the site evolves — and it will — you expand the namespace, not reinvent it.

2) Conventions you can lint

File naming: kebab-case; one concept per file.
Content schema: front-matter validated by JSON schema or Eleventy data cascade.
Commits: conventional commits — your changelog writes itself.
Images: pre-commit hook compresses to WebP, caps dimensions, and rejects files over your budget.

3) The two-way door rule

Any change that can’t be rolled back easily is an anti-pattern. Atomic deploys, tagged releases, and a one-command rollback path keep you bold without being reckless.

4) Content-first routing

Don’t bury URLs in templates. Generate routes from content data. Locations, services, categories — all extensible from content files, not manual router edits.

5) Migration playbooks

Write migrations like features: explicit inputs, scripted transforms, verifiable outputs. New section? New locale? New design system? Run the playbook, review the diff, ship.

Access & Permissions

“Just email it” is how sensitive files end up in personal inboxes forever. Control access with roles and remove one-off file transfers from your workflow.

View-only: final deliverables and references.
Edit: collaborators working on shared drafts.
Admin: project leads managing the structure itself.

Audit quarterly. Offboard immediately. Security isn’t paranoia — it’s professionalism.

Integrate Assets Into Real Workflows

Organization dies if it doesn’t live where people work. Assets should plug directly into your design files, repos, and project trackers:

Design assets linked inside Figma projects.
Copy drafts referenced in GitHub pull requests.
Contracts attached to CRM client records.
Blog images compressed and committed alongside Markdown.

Close the loop and you eliminate scavenger hunts across five platforms for one logo.

Automation Without Mayhem

Automate only after your structure is stable. Otherwise you’re accelerating entropy. What we automate:

Convert and compress all blog images to WebP under a strict size budget.
Lint file names and reject forbidden characters.
Auto-archive completed project folders to cold storage.

Validation: Trust, But Verify

“Best practices” aren’t best until they’re enforced. Make correctness a build step, not a suggestion.

Pre-commit: Prettier, ESLint/Stylelint, gitleaks (secrets), image budget checks.
CI: build the site, run link checkers, HTML validation, schema tests; fail fast.
Performance budget: Lighthouse/PSI thresholds for LCP/INP/CLS; block merges on regressions.
Accessibility: axe-core on critical templates; color-contrast enforced in design tokens.
SEO sanity: unique titles/descriptions, canonical tags, JSON-LD validation on blog and location types.

The output is simple: green lights in CI, green lights in analytics, fewer surprises in production.

Kickstart Checklist

Initialize Git with README, .editorconfig, .gitignore, and .env.example.
Adopt conventional commits + a PR template checklist (perf, a11y, SEO).
Create /docs/assets-catalog.md listing off-repo storage (bucket, path, retention, license).
Wire pre-commit hooks (format, lint, secrets, images). Guard the repo at the gate.
Set up CI with build, link check, schema tests, Lighthouse budget, axe checks.
Document rollback and disaster recovery: where assets live, how to restore, who to ping.

The Bottom Line

Organizing client assets isn’t about being neat. It’s about speed, liability, authority, and trust. The right system makes delivery faster, errors rarer, and outcomes better. For SMB clients, that translates to tangible ROI: better campaigns, faster launches, less wasted spend.

At Maelstrom Web Services, this isn’t optional. It’s how we work. When you hire us, you’re not just buying design or code — you’re buying the discipline behind it. That discipline is what keeps projects on time, on budget, and free of ugly surprises.

Test your own system: find your client’s canonical logo right now. If it takes more than 30 seconds, you don’t have an organization system — you have a liability.