What finally worked for me is almost embarrassingly simple: a single folder of plain Markdown files and two command-line tools to search it. No sync service lock-in, no database, nothing that breaks when an app changes its pricing.

The folder

Everything lives in one directory. I don't use deep folder trees, because I never remember which branch I put something in. Instead the structure is in the file names:

notes/
  2026-10-14-interview-questions.md
  2026-10-17-idea-slow-reading.md
  2026-10-20-quotes-on-editing.md
  inbox.md

The date at the front sorts everything chronologically for free. The rest of the name is a few words I'd actually search for. inbox.md is where quick scraps go when I don't have time to make a proper note; I empty it once a week.

A few lightweight conventions

Search only works if you put the right words in. I keep three small habits:

• Tags as plain words with a hash, like #editing or #idea, on the first line. No special syntax needed, any search tool can find them.
• One topic per note. If a note starts covering two things, I split it. Short notes are easier to find and easier to reuse.
• Write the question, not just the answer. "Why do long intros lose readers?" is a much better search target than a bullet list of facts.

Searching with ripgrep

ripgrep (the command is rg) searches the contents of every file in a folder, very quickly. It's my main tool.

# every note that mentions "first sentence", case-insensitive
rg -i "first sentence" ~/notes

# only list the file names
rg -il "first sentence" ~/notes

# all notes tagged #editing
rg -l "#editing" ~/notes

# show two lines of context around each match
rg -i -C 2 "pacing" ~/notes

Because the folder is just text, results come back almost instantly, even with thousands of notes.

Picking a result with fzf

fzf is a fuzzy finder. You pipe a list into it and it gives you an interactive filter where you type a few letters and it narrows the list down. Combined with ripgrep, it turns the folder into something that feels like a proper search app.

I wrapped the parts I use daily in three small shell functions in my .bashrc. The first two are for finding things:

# n: find a note by name and open it
n() {
  local f
  f=$(cd ~/notes && rg --files | fzf --preview 'head -40 {}') || return
  ${EDITOR:-nano} ~/notes/"$f"
}

# ns: search inside notes, then open the chosen match at that line
ns() {
  local hit file line
  hit=$(cd ~/notes && rg -n -i --no-heading "${1:-.}" | fzf) || return
  file=${hit%%:*}
  line=$(echo "$hit" | cut -d: -f2)
  ${EDITOR:-nano} +"$line" ~/notes/"$file"
}

Now n lets me type a few letters of a file name, and ns pacing shows every line that mentions pacing, lets me pick one, and opens the note right at that spot. Both nano and nvim understand the +line argument; for other editors you may need to adjust it.

New notes with one command

The other half of the problem is friction when capturing. If making a note takes more than a few seconds, I won't do it. So the third function is for writing:

# nn: create a dated note with a slug from the arguments
nn() {
  local slug
  slug=$(echo "$*" | tr '[:upper:]' '[:lower:]' | tr -cs 'a-z0-9' '-' | sed 's/-$//')
  local f=~/notes/$(date +%F)-${slug:-note}.md
  [ -f "$f" ] || printf '# %s\n\n' "$*" > "$f"
  ${EDITOR:-nano} "$f"
}

nn idea slow reading creates 2026-10-21-idea-slow-reading.md with a heading and opens it. That's it.

What I like about this setup

• It's fast. Searching is quicker than any app I've used, and I never wait for a sync spinner.
• It's portable. The notes open in any editor on any system. If I stop using these tools tomorrow, nothing is lost.
• It works with other tools. Most Markdown editors can open the same folder, so I can still browse the notes visually when I want to. And the folder fits naturally into a Git repository if you want history.
• It encourages better notes. Knowing that I'll search by words makes me write clearer, more specific notes.

What it doesn't do

It's not great for images or PDFs, and there's no pretty graph of connections between notes. For me that's a fair trade. Most of what I need to find again is a sentence or an idea, and words are exactly what this setup is good at.

If you want to try it, start small: make the folder, install ripgrep and fzf, and copy the nn and ns functions. Use it for a week before you add anything else.

How do you search your own notes? I'm always curious about other people's small shell helpers.

1. One folder, one file per piece

Every project gets its own folder, and every piece its own .md file:

writing/
  2026-10-blog-writing-routine.md
  2026-10-newsletter.md
  ideas.md
  README.md

Putting the date first keeps everything in order automatically. ideas.md is a plain list of loose thoughts. README.md explains in three lines what the folder is for, so I still understand it six months from now.

2. Frontmatter for metadata

At the top of every file there's a small YAML block:

---
title: Why I write every morning
status: draft
tags: [writing, routine]
---

Plenty of blogging platforms and static site generators read this directly. And I can see at a glance which pieces are still in draft.

3. One sentence per line

This sounds odd, but it works really well. I put every sentence on its own line. Markdown joins lines within a paragraph anyway, so readers never notice. The benefit: when I rewrite one sentence, Git shows exactly that one line as changed instead of an entire paragraph.

4. Small commits with clear messages

git add 2026-10-blog-writing-routine.md
git commit -m "Shorten intro, add second example"

I commit after every real writing session. I write the message for myself three months from now: what changed and why. If I want to go back to an earlier version, it's right there in git log.

5. Look at changes word by word

A regular git diff compares whole lines. For prose, this is much more useful:

git diff --word-diff

It shows you, word by word, what was removed and what was added. It's like track changes in a word processor, without the document drowning in red strikethroughs.

6. Branches for experiments

Not sure about a different structure for a piece? I create a branch:

git switch -c new-structure

If it doesn't work, I switch back to main and nothing is lost. If it does, I merge it.

7. Export when someone wants Word

Not everyone works in Markdown. With Pandoc you can convert a file in a single line:

pandoc 2026-10-blog-writing-routine.md -o writing-routine.docx

My source always stays plain text, and the other person gets the format they're used to.

Why this works better

Plain text doesn't break, opens in any editor and will still be readable in twenty years. Git gives you a full history without you having to think about it. It takes an afternoon to get used to. After that, you won't want to go back.

How do you manage your writing? I'm curious whether anyone has automated this even further.