MAC STORAGE: FREE SPACEBuilding the storage product I needed when my Mac had less than 1 GB free.
I could delete an app and buy myself another day. I still could not explain what kept growing, who owned the space, or which change was safe. Mac Storage grew from that problem into a product that turns evidence into one clear decision at a time.
THE STARTING POINT
The problem was not deleting files. It was knowing what to trust.
When storage was nearly gone, search results sent me through cleanup recipes, forum threads, terminal commands, and broad categories such as System Data. Each answer solved a small part of the problem. None gave me a reliable picture of why space was changing or what a particular action would put at risk.
That changed the product question. Instead of asking, “What can I delete?” I asked, “What evidence would let a person make a good decision?” The answer required ownership, current use, recoverability, an exact identity, and a measured result.
A storage number becomes useful only when it is connected to an owner, a decision, and an outcome.
PRODUCT EVOLUTION
Each version removed one more reason not to trust the recommendation.
The earliest work focused on visibility: name the large storage owners and preserve unknown areas as unknown. The next problem was attention. A long inventory may be accurate, but it leaves the person doing the product’s job. Ranking had to account for useful recovery, present use, confidence, recoverability, and the cost of being wrong.
Once the app could suggest a strong next step, the safety boundary had to become exact. A category name or a display label was not enough. Every proposal needed one stable target, a fresh preflight, a clear statement of what would stay untouched, and separate human approval.
The final gap appeared after successful actions. Some tools remove an item without returning capacity to macOS. Docker and Colima can keep that space reusable inside a virtual disk. Reporting that as Mac-free space would be technically convenient and wrong for the person using the product. Verification therefore became part of the product, not a receipt added at the end.
THE PRODUCT CHOICES
Five decisions shaped the experience.
- 01
Lead with the largest useful decision
Do not spend someone’s attention on 13 MB when a safe multi-gigabyte choice is ready. Size matters, but only after present use, confidence, and recoverability are considered.
- 02
Keep unknown storage honest
Denied access, stale evidence, and timeouts never become zero. The product should reveal the limit of its knowledge instead of manufacturing certainty.
- 03
Separate advice from authority
AI can make dense evidence understandable. It cannot approve a change, silently invoke a tool, or weaken a deterministic safety check.
- 04
Make identity the action boundary
Names collide and paths move. Approval is tied to an exact target that is resolved again immediately before any change.
- 05
Report where the capacity became usable
Space returned to the Mac and capacity reusable inside another application are different outcomes. The interface says which one happened.
TECHNICAL TRUST MODEL
AI is useful here because its authority is narrow.
Storage is messy. The same number can represent personal files, disposable caches, immutable app builds, active databases, cloud placeholders, virtual disks, or data that belongs to another app. Language models are good at explaining these differences and relating evidence to a person’s goal. They are not the right component to authorize a destructive action.
I separated the system into four responsibilities. This keeps the reasoning flexible while the authority path remains narrow, testable, and inspectable.
- 01
Evidence first
Measure allocated bytes, ownership, current-use signals, and recovery evidence before asking a model or a person to reason about the item.
- 02
AI inside a boundary
Give AI a narrow evidence packet. It can explain, compare, rank, and propose. It receives no authority to approve or invoke a change.
- 03
One exact approval
Resolve a stable target, run a fresh deterministic preflight, and show the person what will change and what will remain untouched.
- 04
Prove the post-condition
Confirm the approved identity changed, protected data remained, and the recovered capacity became usable where the product says it did.
Privacy follows the same boundary. The App Store edition uses App Sandbox and folders chosen through the native macOS picker. Storage evidence stays local. Access remains visible and revocable. A changed identity, active dependency, denied permission, stale scan, or unproven recovery path removes the action instead of relaxing the rule.
WHAT THE BUILD TAUGHT ME
The interface is where the technical model becomes trustworthy.
Permissions could not be a surprise prompt. Unknown storage could not look like empty storage. A successful command could not be the same as recovered Mac capacity. Technical evidence had to remain available without becoming the main screen for everyone.
Those constraints produced a product that adapts its depth. A normal Mac owner sees the cause and one next step in kitchen English. An engineer can inspect the target identity, dependency evidence, recovery path, and verification record. Both people use the same safety model.
This is the kind of product work I find most interesting: start with a lived problem, follow it into the technical system, and keep reducing complexity until the person can make a confident decision without surrendering control.