Underneath the feature lists, note apps offer three organizing models: folders, tags, and links. Each one works well for a particular kind of recall, and each one fails in a specific, predictable way. This is a guide to choosing the failure you can live with — before you spend another weekend migrating apps.
The short version
Pick the model that matches how you retrieve, not how you file.
- You remember where you put something → folders
- You remember what it was about → tags
- You get back to things by starting from something related → links
Filing is the part that feels like organizing. Retrieval is the part you actually need it for, and it's easy to design a system for the first and never test it against the second.
| Model | Fits retrieval by | Breaks when | Ongoing cost |
|---|---|---|---|
| Folders | Remembering a location | An item belongs in two places at once | Low, until the tree stops matching your work |
| Tags | Remembering an attribute | Nobody maintains the vocabulary | Continuous, and invisible until it's already broken |
| Links | Starting from a related note | There's no entry point back in | Moderate — every note needs a way back |
Folders
One item, one place. The container is exclusive, and the hierarchy is visible, which is the whole appeal: the location is itself a fact you can remember, and you can browse without knowing what you're looking for. There is no vocabulary to maintain, because the tree is the vocabulary and it's sitting right there in the sidebar.
Where it fails: the two-places problem. A note about pricing for a specific client belongs in the client folder and in the pricing folder. You pick one. Six months later you look in the other. The usual workarounds each cost something — duplicating the note means two copies that drift apart, and declaring a "primary" home means remembering the rule you invented for yourself.
The second failure is slower. A folder tree encodes what your work looked like when you built it. When the work changes, the tree doesn't, and reorganizing a branch means re-deciding every item in it.
Fits: work with genuinely exclusive boundaries — per client, per project, per year — and people who navigate rather than search.
Fails: cross-cutting material. Reference notes, ideas, anything that legitimately belongs to two projects will fight the tree every time.
Tags
Many labels per item, no hierarchy required. This solves the two-places problem head-on: the pricing note gets both labels and turns up in both queries.
Where it fails: vocabulary drift. #writing, #write, and #writing-projects are three tags for one idea, and a query on any one of them misses everything filed under the other two. A tag system is a shared vocabulary with a single contributor — you, across years, in different moods, at different levels of patience. Nothing enforces consistency unless you do.
Tags also accumulate. A tag applied to exactly one note is doing no organizing work; it's just a word attached to a page. Enough of those and the tag list stops being something you can hold in your head, which was the point of it.
The maintenance that keeps this working is unglamorous: keep the list short, prefer renaming an existing tag over inventing a neighbor, and look at the whole list occasionally rather than only at the tag you're typing.
Fits: people who recall attributes — "it was a draft, it was about pricing" — rather than locations. Compared with tag sets you keep adding to as you go, a closed and deliberate one drifts far less. Status tags like #draft / #active / #archive tend to stay stable, because there are few of them and the meanings are obvious.
Fails: anyone who won't do the upkeep. An unmaintained tag system degrades quietly. It keeps returning results, just not all of them, and you have no way to notice what's missing.
Links
Notes point at each other, and retrieval is navigation: you open something you remember, and walk to the thing you don't. Backlinks — an automatic list of every note pointing at the one you're reading — make those connections two-way without extra work.
This captures relationships a tree can't express and a flat tag list flattens. It follows the shape of the material rather than the shape of a filing cabinet.
Where it fails: no entry point. A densely connected set of notes with no doors into it is unreachable in practice. You can only get to a note if you're already standing next to it. If you can't recall the title, can't recall a phrase inside it, and nothing you'd naturally open links to it, the note exists and is gone at the same time.
The fix is deliberate hub notes — index pages, or maps of content — whose only job is to link out to everything in a given area. They're also easy to skip: writing one produces no new material, so it rarely feels like the most urgent thing to do.
Fits: thinking work that returns to the same material over a long stretch — research, writing, a design decision you keep revisiting.
Fails: lookup material you consult once and never think about again. Receipts, meeting logistics, snippets. Linking those is effort with no payoff.
Search changes the math
Full-text search is a fourth retrieval path, and it ignores all three models. If your notes are plain text and the search is fast, much of your retrieval collapses into typing a phrase you remember.
The limit is real, though: search only finds words that are actually in the note. It can't surface "that thing about pricing" if you never wrote the word pricing. That's an argument for descriptive titles, and for stating a note's subject inside the note instead of assuming context you'll still have later.
Combining them without making it worse
The three models aren't exclusive. A workable combination gives each one a single job:
- Folders for the boundary that's genuinely exclusive (usually a project or a client)
- Tags for a small, closed set of states — status, not subject
- Links for anything conceptual, plus a few hub notes so there's a way in
One model per question. Trouble starts when two of them answer the same question — a project folder and a project tag — because now every new note requires a decision, and every search requires remembering which decision you made last time.
Who should skip all of this
- If your collection is small enough to scan in one screen. You don't have a retrieval problem yet. Building structure now is procrastination with a productivity costume on.
- If your notes are short-lived. A scratchpad you clear out regularly needs no model at all.
- If you're switching apps to fix an organizing problem. A new app changes which model is the default. It doesn't make the decision for you, and the two-places problem will be waiting on the other side.
The one thing to do next
Think back over the last few things you went hunting for in your notes, and how you tried to find them. Did you navigate to a place, filter by a property, follow a trail from something related, or type a phrase into search? Build for the one you actually did — and let the rest of your notes stay messy.