Gravity's Missing Features Are the Product

Someone recently asked me why Gravity doesn't have folders.

My first instinct was to say "we'll add that eventually." Then I caught myself. We're not adding folders. We're not adding tags either, or bidirectional links, or a plugin system, or templates, or a knowledge graph.

These aren't items on a roadmap we haven't gotten to yet. They're deliberate omissions. The missing features are the product.

By the end of this post, you'll understand:

• Why note-taking apps keep adding features that make them worse for note-taking
• The specific cognitive costs of folders, tags, and links
• What it means to design a tool around capture friction instead of retrieval power

The retrieval assumption

Every note-taking app makes the same assumption: the hard problem is finding things later.

If retrieval is the goal, then organization is the solution. Folders help you browse. Tags help you filter. Links help you navigate. Search helps you query. Each feature exists to solve the retrieval problem.

There's just one issue: most notes are never retrieved.

Think about the last 100 things you jotted down. How many did you actively go looking for later? For me, it's maybe 5-10%. The rest served their purpose in the moment of capture—offloading from working memory, clarifying a thought by writing it down, creating a record I could theoretically access but never actually do.

If 90% of notes exist purely for the relief of capturing them, then optimizing for retrieval is optimizing for the wrong thing. You're building elaborate infrastructure for a use case that rarely happens, while adding friction to the use case that always happens.

Gravity inverts the assumption. The hard problem isn't retrieval. It's capture—specifically, making capture so fast and frictionless that you actually do it consistently.

What folders cost you

Let's say you have folders. Work and Personal. Inside Work, you have Projects and Reference. Inside Projects, you have the names of active projects. Sensible hierarchy.

Now you have a thought: a half-formed idea about a problem you're working on.

Where does it go?

Is it Work/Projects/ProjectName? Is it Work/Reference because it might be useful for other projects? Is it Personal because you thought of it at home? Should you create a new folder for "half-formed ideas" and if so, where does that live?

You spend 5-15 seconds figuring out where to put something that took 3 seconds to think. The friction isn't huge, but it's there. And it compounds across every note, every day.

Worse: you have to remember where you put things. Six months from now, you search for "that idea I had about X" and can't find it because it's filed under a folder you forgot you created.

Gravity's answer: there's one place. The stream. Everything goes there. The question "where should this live?" doesn't exist because there's only one where.

What tags cost you

Tags were supposed to fix folders. Now things can have multiple labels! No more agonizing over hierarchy!

In practice, tags create a new problem: maintaining consistency across an ever-growing taxonomy.

I have exactly 137 notes tagged #ideas in Notion. I also have 23 tagged #idea (singular). And 41 tagged #thoughts, which is basically the same thing. Then there's #concepts, which I used for about three weeks before forgetting about it.

Every time I tag something, I'm betting that Future Me will remember this tag exists and use it for searching. Usually, Future Me forgets. The tag sits in a sea of similar tags, and eventually I give up on tagging entirely—which means the whole system collapses.

The fundamental issue: tags require you to predict, at capture time, how you'll want to retrieve later. That's asking for taxonomic thinking in the exact moment you're trying to clear your head.

Gravity's alternative: use text prefixes if you want (todo:, read:). They're just characters—no system to maintain, no consistency to enforce. If you forget to use them, nothing breaks.

What links cost you

Bidirectional links are clever. Note A references Note B, and Note B automatically shows a backlink to Note A. Build enough of these and you get a knowledge graph—a web of connected ideas you can explore visually.

Here's what actually happens: you spend time linking notes together. Your graph grows. It looks impressive. You occasionally wander through it, seeing connections. And then... not much.

The graph is a map of what you explicitly linked, which is a subset of what you thought was connected at the time you wrote each note. It's not a map of what's actually connected in your thinking.

Meanwhile, every link is maintenance. When you write something new, you wonder: should this connect to my existing clusters? The more notes you have, the harder this question becomes.

For researchers synthesizing hundreds of sources into coherent arguments, the overhead is worth it. For daily capture and review? The linking becomes another job.

Gravity: notes don't link to notes. Each thought is atomic. The only relationship between notes is time—when you captured them. You scroll through a stream, not a graph.

The feature treadmill

Here's the pattern:

1. Start simple. Text file. Apple Notes. Just write things down.
2. Hit a perceived limit. "I can't find anything!"
3. Add organizational features. Folders. Tags.
4. Discover new friction. Too many folders. Inconsistent tags.
5. Add more features to manage the friction. Search. Filters. Views.
6. Discover that managing the features is itself friction.
7. Add meta-features—templates, plugins, workflows—to systematize the management.
8. Realize you're now maintaining a system instead of taking notes.
9. Start over with something simple... or give up.

This isn't a failure of any specific app. It's an inevitable consequence of optimizing for retrieval in a domain where retrieval isn't the core job.

The more retrieval power you add, the more organizational overhead you create. The more overhead, the more friction at capture time. The more friction, the less you actually capture.

Gravity's constraint

Gravity has one job: minimize the time between "I have a thought" and "the thought is captured and I can move on."

Every feature decision flows from that constraint:

Why no folders? Choosing a folder adds seconds per capture and cognitive load.

Why no tags? Maintaining a taxonomy adds friction and inevitable inconsistency.

Why no linking? Building a graph is a separate activity from capturing thoughts.

Why no templates? Templates are for structured workflows. Capture is unstructured.

Why no plugins? A fixed feature set means less to think about.

The result is an app that does less. Deliberately. Because doing less enables the one thing that matters to happen faster.

What Gravity is for

Here's the specific use case:

You have a thought—any thought. A todo. An idea. A quote. A reminder. A fragment you don't want to forget. You capture it immediately, with zero decisions about where it goes or how to categorize it, and move on with your day. The thought is out of your head and somewhere persistent.

Later—minutes, hours, days—you scroll through your stream. Most things sink toward the bottom, exactly as they should. But some things catch your eye: ideas still alive, todos still relevant, half-thoughts that suddenly connect to something else. You swipe right, they jump to the top. Rescued.

This is it. The entire interaction model. Append, review, rescue. Everything else that note-taking apps offer—folders, tags, links, graphs, templates, plugins—is deliberately not here.

The honest "not for"

Gravity is not for:

• Complex project management. If you need Gantt charts, dependencies, and team assignments, use a PM tool.
• Research synthesis. If you're writing a dissertation and need to track hundreds of sources, you need something else.
• Collaborative workspaces. Gravity is for solo thinkers. No sharing, no comments.
• Long-form drafting. Write fragments here, export essays elsewhere.

These are genuine limitations. If your work requires these capabilities, Gravity isn't just suboptimal—it's wrong for you.

But notice that all these use cases have something in common: they're not really about capturing thoughts. They're about organizing information, managing complexity, or producing artifacts.

If what you actually need is a low-friction thought capture tool... the "missing features" stop looking like limitations and start looking like the point.

The question to ask yourself

Here's a diagnostic I find useful:

In the last month, how much time have you spent inside your note-taking app organizing, categorizing, linking, or restructuring—versus actually capturing and using thoughts?

If the ratio tilts toward maintenance, your tool is eating your attention. More features won't help. More features will make it worse.

What helps is removing the overhead. Using a tool that has nothing to maintain. Trusting that what matters will surface naturally, without you having to architect the surfacing.

Gravity is what that philosophy looks like as an app. One stream. No structure. Let time and attention do the organizing.