For a long time, "just add folders" was the most common piece of feedback I got.
It came from good people, saying it for good reasons. Some of them had come from Pocket, or Notion, or Evernote, and had spent years building a folder structure they were genuinely fond of. To them, a save-everything app without folders looked less like a design choice and more like a feature we hadn't gotten around to yet. A few people said it plainly: "this is great, just add folders and I'll switch."
I sat with that for longer than I probably should have, because it's the kind of feedback that sounds completely reasonable and is also, I think, the wrong thing to build.
The case for just doing it
The pragmatic argument was simple. People were asking. It's not hard to build. It would remove an objection that was costing us actual users, people who liked everything else and bounced at the exact moment they realized there was no folder icon anywhere in the app.
There's a version of this post where that argument wins, and honestly, on a bad week, it almost did.
What folders actually do to how you save things
Here's the problem I kept coming back to. The moment you offer folders, you've changed what saving something means. It's no longer "keep this," it's "keep this, and also decide where it lives." That second part sounds small. It isn't. It's a decision made under the worst possible conditions: right when you found the thing, before you have any idea how you'll actually think about it later.
I'd watch this happen in my own usage before we'd even shipped anything close to folders, just in how I used other tools. I'd save something, then pause, staring at a folder picker, trying to guess whether "Design Inspo" or "Reference" or a new folder I'd have to name on the spot was the right call. Half the time I'd give up and just leave it in the default location, which meant the folder structure existed and also wasn't being used, which is worse than not having one, because now there's a system quietly failing in the background and making you feel bad about it.
That's the pattern we kept seeing described back to us in different words: "I have a folder system, I just don't really use it anymore." Nobody was saying the folders were badly designed. The timing was the problem. You cannot ask someone to categorize something correctly before they know what it's for.
What we built instead
We didn't just say no and leave it there, because "no folders, deal with it" isn't a real answer to a real pain point. What we built is Pockets: an entirely optional way to group things after the fact, once you already have enough saved that a pattern is obvious. You don't have to make a Pocket before you save something, and most things never end up in one at all. If you look at your library three months in and notice you've been saving a lot of packaging design references, you can pull those into a Pocket in ten seconds, after the fact, once you actually know what you're grouping and why.
That's the real distinction, and it took a while to articulate clearly even internally. It's not "organize or don't." It's "organize before you know what you're organizing, or organize after, once you do." We picked after, and made it optional, because the whole premise of Trase is that saving something shouldn't come with homework attached.
The part I'm still not sure about
I won't pretend this fully resolved the tension. Some people genuinely like the up-front structure, the same way some people like a clean desk and some people work fine out of a pile. For those people, an optional after-the-fact Pockets feature is a smaller offering than the folder system they're used to, and that's a real trade-off, not a false one.
What I am sure about is that if we'd added folders as a checkbox feature to quiet the feedback, we'd have quietly reintroduced the exact problem the whole product is trying to solve. The goal was never zero structure. It was structure at the right moment, instead of the wrong one.