2
1 Comment

Collections looked like a simple feature. They’re turning into the core product decision.

I’ve been spending a lot of time lately refactoring the collection experience in Voyager.

Voyager started from a pretty simple belief: file management is still stuck in a folder-first model, while actual work is much more contextual. So instead of treating files as things that only live in folders, we’ve been building around attributes, related files, and collections. 

What surprised me is that collections looked like a straightforward feature at first, but they’re turning into one of the hardest product decisions.

If collections are too lightweight, they feel disposable. People create them, but never come back.
If they’re too structured, they feel heavy. People hesitate before creating them at all.

That tension has been driving a lot of my recent work.

I’m refactoring the flow around:
• when a collection should be created
• how much should be automatic vs explicit
• what makes a collection feel like a working set instead of passive storage

This has changed how I think about Voyager.

I used to think the hard part was “help users find the right files.”
Now I think the harder part is “give them an output they can actually keep working from.”

We already built system-attribute-based collection definition and natural-language collection creation, and now I’m trying to make the collection behavior itself feel much more coherent. 

Would love to hear from anyone who has worked on search, PKM, productivity, or file workflows:
how did you think about the balance between lightweight and structured?

If you’re curious what Voyager looks like today, it’s here:
voyager.fm

posted to Icon for group Building in Public
Building in Public
on March 9, 2026
  1. 1

    The lightweight vs. structured tension is real, and it shows up in almost every workflow product.

    We ran into the same thing building the email sequence configuration for tryrecoverkit.com — payment recovery sequences for failed Stripe payments. Too lightweight (one generic email, no customization) and recovery rate stays low. Too structured (configure your own templates, set custom timing, define stop conditions) and founders never finish the setup.

    The insight: the distinction matters less than which direction the default error fails in. For collections — creating something too lightweight and never returning has a low cost; starting to structure something seriously and abandoning it halfway is more damaging. So your default should protect against the more expensive failure mode.

    For recovery sequences, the same logic led us to ship a single opinionated D+1/D+3/D+7 default you can't misconfigure, rather than a flexible builder. Removing configuration options actually increased completion rate. Same tension, same resolution.

Trending on Indie Hackers
6 weeks solo, 2 rejections, finally live but nobody told me marketing would be this hard User Avatar 134 comments Building ExpenseSpy solo, no funding — launching June 17 on iOS & Android User Avatar 56 comments I spent more time setting up cold email than actually selling. Here is what fixed it. User Avatar 22 comments I just wanted to taste AI coding tools. A week passed. User Avatar 17 comments Building LinkCover – Day 3: Payment is live. No more building, time to sell. User Avatar 15 comments I Was Bypassing Every App Blocker, So I Built One That Fights Back User Avatar 11 comments