Your files aren’t messy. They’rejust 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.
This is a strong product insight because the problem is not really “file organization.” It is context decay. People save files correctly at the time, but months later the folder structure no longer matches how they remember the work, why it mattered, or where it should be reused.
That makes Voyager more interesting than a better Finder. The sharper category might be closer to a context layer for local files: reusable collections, properties, natural-language views, and eventually an agent that helps old work become findable and useful again.
One thing I’d watch is the name. Voyager is clean, but it may be hard to own and search for because it is so broad. If this becomes a serious local-first workflow layer for files and projects, Xevoa .com would give it a more distinct platform-style brand.
This is really helpful, thank you.
“Context decay” is a great way to describe the problem. The file is usually saved correctly at the time, but the surrounding meaning slowly disappears: why it mattered, what it was connected to, and where it becomes useful again.
I also like the “context layer for local files” framing. That feels much closer to what we’re trying to build than simply being a better Finder.
On the name, I get your point. We’re likely going to keep Voyager for now, but the broader framing around context persistence and reusable collections is something I’m taking seriously.
That makes sense.
Voyager is clean, so I get why you’d keep it for now.
The thing I’d pressure-test is not whether Voyager sounds good. It does. The risk is whether it is specific and ownable enough once the product becomes more than file navigation.
“Context decay” and “context persistence” are much sharper than better Finder. That is the part users may actually remember.
If Voyager makes people think exploration or browsing, but the product is really about preserving the meaning around old work, there may be a gap between the name and the category you are creating.
That gap matters more as the product gets stronger.
I’d probably watch one thing closely: do users describe it as a file explorer, or as the place where old work becomes reusable again?
If it is the second, then the product may eventually need a name that carries the context layer more clearly than Voyager.
That’s a really good distinction.
I think the “place where old work becomes reusable again” framing is much closer to the feeling we’re aiming for than traditional file navigation.
For now, I still like Voyager because it feels approachable, but I do think the category itself is slowly becoming clearer through conversations like this.
Especially the shift from “finding files” to preserving and recovering context over time.
One practical thought here.
Since the product category is still becoming clearer, a full rename may be too early, but the naming and positioning layer is worth pressure-testing before more users and product memory build around Voyager.
I do focused naming/positioning audits for early products: current name risk, category framing, domain/name ceiling, what users are likely to assume from the name, and what stronger direction I’d take if the product grows beyond the current wedge.
For Voyager, the useful question would be whether the name can keep carrying the product if users start describing it less as file navigation and more as context persistence, reusable work memory, or recovering old work over time.
It is not a long consulting thing. Just a sharp written breakdown with practical recommendations.
I’m doing a few of these at $99 while refining the format. If useful, connect here and I can give you a clear outside read before the category gets more fixed:
https://www.linkedin.com/in/aryan-y-0163b0278/
That makes sense. I would not force a rename too early if Voyager still feels right internally.
The only thing I’d separate is “approachable” from “durable.”
Voyager is approachable because it feels familiar and easy to understand. But if the product keeps moving toward context persistence, reusable work memory, and recovering meaning over time, the brand may need to carry more than navigation.
That is where the gap can show up later. Users may like the product, but still describe it in a smaller frame than the one you are actually building.
I’d keep watching the language users naturally repeat back to you. If they keep saying “file explorer,” Voyager is probably fine. If they start saying “this helps me recover old work and context,” then the category may be bigger than the name.
That is where a more ownable platform-style name like Xevoa would make more sense, but only if the product keeps expanding in that direction.