Your files aren’t messy. They’re just stuck in the wrong system.
Hey IH,
Time isn’t unlimited, but we keep wasting it looking for files we already made.
I’ve been interested in file workflows for a long time, especially what happens after something is saved.
Most knowledge workers don’t explicitly think of file management as a productivity problem. But in practice, a surprising amount of time gets lost to finding, reorganizing, or recreating files that already exist.
This becomes especially noticeable when you’re working across multiple projects. Founders, designers, and builders all end up with files scattered across different contexts. The files are technically there, but bringing them back into use is where things start to break down.
The interesting part is that people do try to organize. They create folder structures, clean things up, and try to stay consistent. But over time, new work comes in, priorities shift, and the structure slowly stops reflecting how they actually think. At that point, maintaining it starts to feel like work on its own, so people stop doing it.
I think the root issue is this: files live in one place, but they don’t belong to just one context.
A single file can be part of a project, related to an idea, useful as a reference, and something you’ll need again later. But folders force you to choose one location, while your memory is based on context.
That gap is what led us to build Voyager.
Voyager is a macOS file manager built around properties and reusable collections instead of folders.
Instead of reorganizing files over and over again, you define context once and reuse it.
For example, you can describe something like “files related to the next launch that still need cleanup” or “large files created this year in Downloads,” and Voyager turns that into a collection that keeps updating itself.
Right now, the beta focuses on two early pieces: property-based views and natural language collection creation.
You can combine things like location, name, extension, creation date, and file size without rebuilding the same search every time.
The next step we’re exploring is an agent layer. Instead of managing everything manually, Voyager should help assign context, update properties, suggest useful collections, and let you work across files more naturally.
The goal isn’t just to find files faster.
It’s to make old work usable again.
We’re currently running a closed beta.
I’m especially curious to hear from people who work across many projects and constantly lose track of what they already made.
If your files are technically saved, but not really reusable, that’s the gap we’re trying to close with Voyager.
You can check it out here:
https://voyager.fm
Would love any feedback.
Voyager is the right idea. Folder systems fail because they force storage logic, not retrieval logic.
The real wedge is not “file management.”
It’s memory recovery.
People are not trying to organize files.
They’re trying to recover past work without rethinking where they put it.
That’s a much stronger frame.
Voyager is really:
the layer between “I made this before” and “where the hell is it?”
That’s the pain worth owning.
Also, Voyager is a decent product name, but it still frames like exploration.
As this gets more serious, the product likely outgrows the softer “discovery” feel and wants a tighter system-grade name.
Vroth.com fits that direction well.
Shorter, sharper, more infrastructure-like.
Voyager works for now.
Vroth feels closer to what this becomes if it turns into core workflow infrastructure.
This is a really interesting way to frame it.
“Memory recovery” actually resonates a lot more than just file management. The moment you described it as the gap between “I made this before” and “where is it?”, it clicked.
That’s pretty much the experience we’ve been trying to get closer to.
On the naming side, I get your point as well. Voyager definitely leans more toward exploration. Curious to see how that evolves as the product becomes more concrete.
Exactly.
Voyager works while the product feels like discovery.
But “memory recovery” is a stronger and more serious category than discovery.
Discovery sounds optional.
Recovery sounds necessary.
That difference matters if this becomes something people rely on daily to get back to work faster.
That’s why I mentioned Vroth.
It feels less like exploring files and more like a core system layer.
If Voyager is the friendly entry point, Vroth feels closer to the infrastructure version of what this could become.