Working product · open source
A native macOS file-curation app I conceived, specified, designed, tested, and now use daily—implemented with AI while product authority remained human.
The problem was mine first
Creative work leaves files across SSDs, SD cards, project folders, exports, email attachments, and reference collections. Finder can show each location, but not the whole project as one coherent working set.
Aerial View turns project membership into a database relationship. Files stay where they are. The app keeps resilient references to them, lets one item belong to several projects, and can still represent files on drives that are not currently connected.
Designed before prompting
Before an AI conversation began, the data model and the long-lived product rules were already explicit: what a Project is, what an Item is, how their many-to-many relationship works, and which boundaries the product must never cross.
When implementation discussions drifted toward live Mail or Notes capture, the existing rule—exported files only, no live capture—made the error visible. The model did not protect the product boundary. The designer did.
AI wrote nearly all the Swift. I authored what the product does, why it works that way, and what it must never do—and enforced those decisions throughout implementation.
Every feature was verified against the real library used for daily work. “The code compiles” was never accepted as a substitute for “the product is good to use.”
The product in use
Engineering depth made reachable
Aerial View now includes a local SQLite database with more than twenty successive migrations, security-scoped bookmarks that survive file moves, an FSEvents folder watcher, on-device natural-language search, and a path-sensitive archive format with checksum verification.
Those are not decorative implementation details. Each one exists because of a product requirement: resilient identity, safe observation, legible search, recoverable organization, and long-term ownership of real working data.
Proof through failure
A sidebar misclick once deleted an entire project containing the organization, ratings, tags, and structure for 178 referenced files. The original files were safe—Aerial View never deletes them—but the curated project vanished without undo.
I recovered the database directly through Time Machine. The app's own restore mechanism could not help because no in-app backup had been created yet.
Root-cause analysis exposed two UX failures: project and category rows were packed too tightly, and category deletion lacked the confirmation required for project deletion.
The answer was not a narrow patch. Editable properties moved into a single inspector, ambiguous pencil actions disappeared, every delete path now requires confirmation, and Aerial View creates an automatic backup whenever the app exits. Real use supplied the evidence; human judgment defined what “properly fixed” meant.
Augmented product designer, not vibe coder
Distribution, data ownership, file safety, relationship logic, volume identity, and platform scope were decided before implementation.
Model suggestions were checked against the product rules and rejected when they crossed a boundary or silently invented behavior.
The app is judged against live working data, removable drives, failures, restores, and daily use—not against the smoothest demo path.
Feature-complete · open source · used daily
Aerial View now works alongside card&board. Neither app depends on the other, but real use of the first revealed the need for the second—the clearest sign that this is a living product practice rather than a portfolio exercise.