A developer's Mac accumulates storage differently from a general-purpose one — not mainly through photos and downloads, but through a rotating cast of package manager caches, build artifacts, and virtual machine images that regenerate as fast as you clear them. A storage tool aimed at that workflow needs to do a few specific things well that a general-purpose tool doesn't have to worry about.
Recognising the shape of developer storage sinks
The biggest single difference in developer storage is volume of small files rather than a few large ones. A node_modules tree for a moderately complex JavaScript project can easily contain tens of thousands of files across thousands of packages, most individually tiny, collectively substantial. ~/Library/Developer/Xcode/DerivedData similarly accumulates build intermediates per project, growing without bound unless manually cleared. A tool built for this workload needs to handle that file count efficiently, not just handle large individual files well.
Beyond raw handling, recognition matters more here than almost anywhere else, because the number of distinct cache types a working developer accumulates is genuinely large: npm and pnpm and Yarn for JavaScript, pip for Python, Cargo for Rust, Gradle and Maven for JVM languages, Homebrew and CocoaPods for macOS-specific tooling, plus Docker's VM disk and Xcode's simulators and device support folders if you're building for Apple platforms. Nobody keeps the safety profile of all of these memorised, and looking each one up manually every time is real friction.
Comparing snapshots over time
A pattern specific to development work is wanting to know not just "how big is this now" but "how much did this grow since last week." A DerivedData folder that's stable at 15GB is different from one that grew from 5GB to 15GB in three days, even though the current-state number is identical — the growth rate tells you something about whether a specific project or build configuration is the culprit.
This requires a tool to either retain scan history explicitly, or make it easy enough to compare two exported snapshots manually (a CSV from last week against a CSV from today, diffed by folder path) that the comparison is actually practical rather than theoretical. Few tools build snapshot comparison as a first-class interactive feature, which makes manual comparison via export the more commonly available path.
Why exclusion patterns matter for a developer's mental model
A general storage tool treats every folder equally on the way in. A developer, though, usually already knows certain folders are going to be large and regenerable — every project's node_modules, every target directory from Rust builds, every .venv from Python — and doesn't need a tool to keep surfacing them as if they were a surprise on every single scan.
The ability to exclude known, expected large-and-disposable folders from a scan's headline results (without excluding them from disk entirely, since they still exist and still occupy space) lets the tool focus attention on what's actually unexpected. This is less about hiding information and more about triage: if you already know your dozen active projects' dependency folders account for 40GB combined, a tool that keeps leading with that fact every time isn't telling you anything new, while a tool that can set that aside and show you what else changed is doing something more useful.
CSV export as a genuinely practical feature, not a checkbox
Exporting a scan's results to CSV sounds like a minor feature until you consider what it enables: piping the data into a spreadsheet for a team-wide audit of shared development machine usage, diffing two exports across time using ordinary spreadsheet tools rather than anything specialised, or scripting a periodic check that flags when a specific project's build folder crosses a threshold.
For a solo developer this might be a rarely-used feature. For anyone managing shared build machines, CI runners, or a team's set of developer laptops, being able to get scan data out of the GUI and into a format a script or spreadsheet can process is the difference between a one-off manual check and something repeatable.
Working across multiple checkouts and worktrees
Developers frequently maintain more than one checkout of the same repository — a main working copy plus one or more Git worktrees for parallel feature branches, or several clones for different clients or experiments. Each checkout typically gets its own node_modules or equivalent dependency folder, since most package managers install per-project rather than sharing across checkouts by default (pnpm's content-addressable store is a deliberate exception, using hard links to avoid this duplication). A storage tool that can show you the combined size of everything matching a pattern like node_modules across an entire projects directory, rather than requiring you to check each checkout individually, saves real time on a machine with a dozen or more active repositories.
This connects back to the exclusion and recognition points above: knowing that fourteen separate node_modules folders sum to 30GB is a different, more useful fact than encountering each one individually as a surprise during unrelated browsing.
CI runners and shared build machines
The considerations in this section apply with extra weight to shared infrastructure — a CI runner or a shared build Mac used by a team — where storage accumulates from many different people's work rather than one person's habits, and where nobody individually feels responsible for cleaning up a cache another team member's build left behind. On this kind of machine, the CSV export and pattern-recognition features matter less as personal conveniences and more as the basis for an actual maintenance routine: a periodic scan, exported and reviewed, to decide what's safe to clear before the machine runs out of space mid-build.
A developer-specific checklist
| Need | What to look for |
|---|---|
| Handles high file counts without slowing to a crawl | Efficient enumeration, not just fast reads of large files |
| Explains unfamiliar caches | Recognition of common package manager and build tool patterns |
| Supports "what changed since last time" | Either built-in history or exportable snapshots to diff manually |
| Reduces noise from known-large folders | Exclusion patterns for expected regenerable directories |
| Supports scripting or team reporting | CSV or similar structured export |
Where VolumeLens fits
The paid Insights tier in VolumeLens recognises node_modules, Xcode's DerivedData and simulator devices, Docker's VM disk, Homebrew and CocoaPods caches, and the caches for npm, pnpm, Yarn, pip, Cargo, Gradle, Maven, and several other common toolchains, labelling each with what it is. CSV export is included in the same tier, so scan results can move into a spreadsheet or a script for comparison over time. The free tier covers the underlying scan, browse, and search functionality without the recognition layer, so you can evaluate the core scanning performance on your own project folders before deciding whether the developer-focused additions are worth the one-time upgrade. See the features page for the full list or pricing for the specifics.