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.
Really strong framing memory recovery actually feels more real than file management or discovery. The real test will be whether it stays reliable when people start depending on it every day.
That’s exactly the part we’re paying the most attention to right now.
If it doesn’t stay consistent when people rely on it daily, the framing doesn’t matter much. Getting that part right feels like the real work.
Test comment from terminal automation — will delete this shortly. Sorry for the noise!
No worries at all haha
This resonates a lot. I've been thinking about the same friction from a
different angle — on iOS, the problem isn't just finding files after the
fact, it's that the filing step itself creates friction at save time.
For CoreFiles (an iOS file manager I just launched), the approach was:
pick the destination folder before scanning/importing, not after.
Reduces the moment of "where does this go?" to zero.
The folder structure problem you're describing is real though —
Quicksave Shortcuts help with the most-used destinations, but
the underlying organization still relies on the user having
a consistent mental model upfront.
Curious whether your approach handles the mobile capture workflow
at all, or is it primarily desktop-focused?
That’s a really useful angle.
Voyager is currently focused on the macOS desktop workflow, so we’re mostly looking at what happens after files already exist across Downloads, Desktop, project folders, and other local locations.
But I agree that the capture moment matters a lot. “Where does this go?” is one of the earliest points where the system starts to break down.
For now, we’re approaching it more from the recovery side: once files pile up across contexts, how do you make them usable again without forcing the user to rebuild the whole structure manually?
I like the way you framed capture and recovery as connected problems.
Yeah this is real.
I feel like the bigger frustration sometimes is not finding files, but trusting them once you do.
That’s a great point.
That trust layer is something we’ve been thinking about more as we work on properties and collections.
The "folders force you to choose one location, but your memory is based on context" line is genuinely the cleanest articulation of this problem I've read.
From the data warehousing world, what you're describing is basically the difference between a hierarchical model (one parent per file) and a tag/property model (many-to-many relationships). Every file system that scales eventually re-invents this — Gmail did it with labels, photo libraries did it with smart albums, and now you're doing it for the macOS file system. It works because the schema matches how humans actually retrieve information: by attributes ("PDFs from this year, related to launch X"), not by location.
One thing I'd watch for as you scale the agent layer: property drift. When you let an agent auto-assign context, the same concept can get tagged five slightly different ways across 1,000 files ("Q4-launch", "q4 launch", "launch-q4"). Most file-tagging products die there. A canonical-property table that the agent reconciles against on write is the unglamorous fix — same approach we use for dimension cleaning in data warehouses.
Question: are you planning a CLI or API for power users? The collection definitions you described feel like they could become a queryable layer that other tools (Raycast, Obsidian, dev environments) plug into.
This is extremely helpful, thank you.
The hierarchical vs many-to-many framing is very close to how we’ve been thinking about the problem, even though we haven’t described it that way publicly yet.
On the CLI / API side, we are starting to think in that direction. If collections become a stable query layer over local files, it makes sense for them to be accessible from other tools as well.
We’re definitely open to integrations with things like Raycast, dev environments as this evolves.
This resonates. The hardest part of file organization isn't the initial sorting—it's building the habit of consistent saving in the moment. Most systems break down not because they're bad, but because they require too much friction when you're in flow state.
What's worked for me: a single 'inbox' folder for everything during the day, then a 10-minute daily review to file things properly. Reduces the cognitive overhead at save time significantly.
This makes a lot of sense.
The “flow state” part is exactly what stands out to me. Most organization systems sound good when you design them, but they break when you’re busy and don’t want to think about where something should go.
The inbox approach is a practical way to reduce that friction.
With Voyager, we’re trying to push that even further: ideally, you shouldn’t have to think much about saving or filing in the moment at all.
If the right context can be recovered later through properties and collections, the user doesn’t have to make the perfect organization decision upfront.
The point about files living in one context but belonging to multiple really resonates, and the same friction shows up when you are capturing ideas. Most people lose thoughts the second they have them because typing feels slower than just moving on. Voice dictation fixes that at the source, get the idea out fast before it disappears, then sort it later. DictaFlow is built for exactly that, hold to talk so you are not fighting your keyboard, with mid-sentence correction so messy speech does not penalize you. The file-finding problem you are talking about might actually be partly a capture problem, fewer ideas slipping through in the first place.
That’s an interesting way to look at it.
I agree that capture plays a big role, especially in those early moments where ideas can disappear quickly.
What I keep running into though is that even when things are captured, they still tend to get lost over time once they become part of a larger pile.
Feels like capture and retrieval are two different layers of the same problem.
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.
That distinction between optional and necessary is really interesting.
“Discovery” does feel like something you can ignore.
But once it becomes about getting back to work without friction, it starts to feel much more fundamental.
The idea of this evolving from a friendly entry point into something more infrastructure-like also makes sense.
Feels like the hard part is getting the experience right first, and then seeing what it wants to become from there.
Yeah, experience comes first.
But I’d be careful with waiting too long on the frame.
The product does not “become” infrastructure only after it is mature.
Users start deciding that from the first few times it saves them from searching, rebuilding, or losing past work.
That is where the name starts shaping the expectation.
Voyager says:
explore what you have
Vroth says:
recover what matters and get back to work
Different mental model.
If you are aiming at daily workflow reliance, I would start testing the stronger frame earlier, not after the product already hardens around discovery.
That’s a really helpful way to think about it.
The distinction between “explore what you have” and “recover what matters” definitely clicked for me.
I still like Voyager as the name, especially at this stage, but the “memory recovery” frame is something I’m taking more seriously now.
Feels like that’s closer to what people actually experience when it works.
That makes sense.
Voyager is not wrong.
The question is whether it gives users the right expectation fast enough.
If the strongest moment is:
“I found the thing I needed and got back to work”
then “memory recovery” is probably the more valuable category to own than exploration.
That is why I’d test the frame earlier, even if you do not rename immediately.
Because once users start describing it as recovery instead of discovery, the naming decision becomes much easier.
Vroth only makes sense if you want the product to feel like serious workflow infrastructure, not a softer file discovery layer.
Yeah, I think you’re right.
The way you framed it helped me separate the name from the category more clearly.
Voyager can still be the product name, but the stronger lesson here is that the value people feel may be much closer to recovery than discovery.
That’s a really useful distinction, and I’ll keep it in mind as we keep testing the product.