How to Organize Client Assets

Why Asset Organization Matters

Every project begins with a flood of files — logos in four formats (none of which you actually need), headshots named final-FINAL.jpg of ex-employees, a half-complete spreadsheet of brand colors that spread 4 palettes, PDFs from the last web agency that failed to make the grade, Word docs with “approved copy-7” as the name, and a WeTransfer link that expires tomorrow at 4AM.

For guidance on structuring your site for search engines, refer to Google’s SEO Starter Guide .

If you run client work, you’ve lived this chaos.

Disorganized assets don’t just waste time — they introduce risk. Liability hides in the mountains of mess that is provided to you by well-meaning clients who often share company assets without fully considering how sensitive some of it may be in a very material way.

The problem isn’t just clutter; it’s cost — even if indirect. Disorganization, whether it be in your intake process or during some phase of the project delivery cycle — burns billable hours, creates rework, and undermines trust. Trust internally is broken on teams and creates resentment when easily preventable mistakes occur, especially if blame is involved (you have bigger problems if your environment promotes blame culture...).

Ship the wrong logo? Use an outdated legal disclaimer?

That’s not inefficiency — that’s legal exposure, and of the worst kind, because the extent is often not well understood until it is too late. So yes, organization as operational hygiene is essential to businesses that thrive for the long run. Depending on your industry, a certain level of organization and secure data retention is likely even mandated by regulatory bodies.

For a quick overview, see the Wikipedia entry on ISO/IEC 27001 .

Principles Before Tools

While this philosophy is much more prevalent in the security and SaaS spaces, it applies with equal pertinence on this subject. As the great media theorist Marshall McLuhan once surmised in his important work, Understanding Media: The Extensions of Man, "all media are extensions of some human faculty, psychic or physical." To speak plainly, technology multiplies natural capacities that already exist, so whatever system you already have in place, for better or worse, will be amplified by your toolset.

Before picking platforms, set rules you can enforce with any stack, in any situation, for any client depending on needs.

• 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.

How you decide to implement these basic concepts is not so much of a concern so much as that they are being implemented at all. When I first started development I was overwhelmed by the disorganization of the intake processes I witnessed and heard about, but even more so by the way development teams handled resources. Discipline with client assets is pivotal to retaining and keeping a healthy reputation and working relationship with others.

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

For a practical blueprint, see File Structure for Speed & Scale .

Folder Architecture That Works

I say this time and time again, and I will keep saying it: 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.

Related: how organizing content like assets builds authority— Building Out Pillar Pages Effectively .

For foundational reading on information architecture and navigation, see Nielsen Norman Group’s Information Architecture: Study Guide .

File Naming Conventions

Random naming conventions (or lack thereof) simply do not function at any sort of enterprise scale — assets go missing, repeated names result in deleted files, sensitive documents get intermingled with public and then need client-eyes to separate again. In many cases, multiple vendors touch the same brand. Confusion stacks without a naming 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, so correct files are obvious.

Git, Or Your Margin Will Disappear

If your files aren’t versioned, you’re gambling with time, trust, and liability. While I don't know any professionals who do not use Git in some fashion, for the sake of being thorough and for newer devs, I want to reiterate the point. Git is non-negotiable. It gives you atomic history, reversible changes, precise accountability, and repeatable releases. If you have ever argued at 1AM on Slack about "what version is safe," then you know Git is important.

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)

• Pro Git (free, canonical book)
• GitHub Skills: interactive courses
• Atlassian Git tutorials
• Learn Git Branching (visual sandbox)

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 — sometimes all three. Treat your active repository like a tower: only the controls that matter to ship should be allowed inside. Everything else is just cargo — so store it safely and 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 costs).
• 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 asset locations live (bucket name, path, retention) so that new collaborators onboard without DM’ing you for the font zip...again...and again.

Build a System That Expands Instead of Breaking

The main lesson I have learned from leading development projects is that growth kills fragile systems. My goal when pouring the foundation of any system is to be boringly predictable: add a page, a section, a locale, an island — nothing falls apart. That kind of solidity in a build requires a few architectural choices up front which often front-load the effort yet pay extraordinary dividends later in the growth process.

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. Naturally, start off broad and imagine if any folder suddenly became 4 layers deeper: would your current system accommodate that?

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 and should not be a part of a professional workflow. Committing to changes on a project with no clear and simple way to revert is like walking through a vault door instead of a revolving one: once you’re in, you’re trapped.

That’s not how resilient systems should behave. I knew I had come up with a stellar work process for my team when we celebrated systems which embraced reversibility. You try something, and if it flops, you can step back out without burning the whole house down and quietly smoking a cigarette on the porch.

Atomic deploys where the entire build is created and pushed in one commit, tagged releases with semantic and clear releases, and a one-command rollback path give you permission to be bold without being reckless.

For clients, that means higher uptime on revenue producing infrastructure, fewer late-night fire drills and "emergencies," and zero SEO meltdowns from botched releases. At Maelstrom Web Services, we treat “rollback in 60 seconds” as a guaranteed and expected feature, not a fantasy we just advertise on paper. Boring is better.

4) Content-First Routing

Don’t hard-code your URLs into developer files like it’s 2005. Please. A modern site should generate its routes directly from the content itself rather than developers needing to get creative about it. Locations, services, categories — these should all live in structured content files that automatically produce clean, predictable URLs when added to the file tree.

This approach makes your site easier to scale and much more SEO friendly because all paths become easily anticipated and logical to follow. Like most developer choices, it goes back to doing everything possible to help Google want to index and rank every site page by being explicit about the content, structure, and nature of your domain.

As an anecdotal rule of thumb, when users can remember how to get to specific pages via your logical URL structure — without any references — you know you were successful in your presentation of site resources.

At Maelstrom Web Services, we call this “content-first” because your URLs mirror the real hierarchy of your business, not a developer’s side notes and dreams of expansion. The result is a system that’s maintainable, crawlable, and built for discovery because clean routes aren’t just tidy; they primarily serve to foster trust and visibility.

For SEO implications of clean routes, read Site Architecture for SEO Success .

5) Migration Playbooks

Big changes shouldn’t feel like obstacles to overcome on a modern website. On a legacy site, I can commiserate with the migraine that is making any significant or meaningful change.

For non-developers, a migration is simply a structured way of moving your site from one known state to another — whether that’s adopting a new design system, adding a feature section, or rolling out an expanded product line.

I keep harping on these concepts of modularity, versioning, scalability, automation as if making the perfect development process wasn't trying to wrangle 1000+ moving pieces together. Please understand that development will always be messy and fraught with nuance — the real question is, do you have different problems than you once did or are they unchanging? Facing new challenges is not a sign of failure but instead of progression.

Access & Permissions

If you are a small firm and currently have a “Just email it” policy, whether it be internal or external, the danger is written on the wall. Role-based access control and zero trust in a complicated system both internally and externally is the new widely suggested standard for a reason.

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

Auditing should be done post-project, or at a minimum, quarterly with offboarding of access happening immediately post-collaboration.

Integrate Assets Into Real Workflows

Organization, no matter how well thought out, is not real until it is a part of natural workflows for your team. Assets should be directly integrated into your design files, repositories, 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.

Closed-loop communication is not a new concept, especially in technology, and yet actually seeing it implemented consistently and effectively is still rare despite the massive upside of standardizing it in some fashion into existing workflows.

Strengthen discoverability with strategic cross-linking: Internal Linking Best Practices .

Automation Without Mayhem

Automation is meant to make an already successful and stable practice even better. To automate a half-baked process is consciously choosing to accelerate entropy.

What we automate, when we are ready:

• 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.
• CSS purging, code minification, hashing resources for integrity

If you’re hashing assets, don’t skip Subresource Integrity (SRI) for tamper-resistant delivery.

Validation: Trust, But Verify

As a team lead, you have a lot of responsibility. One of the greatest duties, however, is to ensure teams are protected from themselves — work limits, versioning, automated blockades in project progression based on established and accepted metrics, etc.

• 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.

When done right, output is fool-proof: all greens and no reds means you can move on.

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 is 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 money.

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