Advertisement
Workflow

How I organize a personal knowledge base after five years

Five years ago I started keeping notes on everything: incidents, architecture decisions, book summaries, half-formed ideas for blog posts, recipes, the exact settings I used on a NAS I'd forget by next year. What started as a folder of markdown files has turned into something I actually trust to hold information I'll need again, which is a much higher bar than "a place where I put notes."

Most writing about personal knowledge management is either evangelism for a specific app or a screenshot tour of someone's beautiful, obviously-never-actually-used vault. I want to write the boring version: what the system is, where it broke over five years, and what I changed because of that.

The short version is that the tool matters less than the habit, and the habit only survives if retrieval is easier than re-deriving the information from scratch. Everything below is in service of that one constraint.

Advertisement

The tools I actually use

I write notes as plain markdown files in a folder synced across machines, and I use Obsidian as the interface for browsing, linking, and searching them, because it reads plain files rather than locking them into a proprietary format. I tried Notion for about eight months in year two; it's a genuinely good product, but the moment I wanted to grep across five years of notes from a terminal, the database-backed model worked against me. I don't think Notion is the wrong choice for most people — plenty of teams run entire wikis on it successfully — it was wrong specifically for how I wanted to retrieve information later.

For quick capture during the day, I use a single always-open scratch file rather than a dedicated app, because switching contexts to open a new tool is exactly the kind of friction that kills the habit on a busy day.

The folder structure that finally stuck

I went through three structures before landing on one that survived contact with real use:

  • Year one: topic-based folders (networking/, databases/, career/). Fell apart because most useful notes are about more than one topic, and I'd forget which folder I filed something under.
  • Year two: a single flat folder with heavy tagging. Better for retrieval, worse for anything resembling a table of contents — I could find individual notes but never got an overview of what I had.
  • Year three onward: a flat folder plus a small number of hand-maintained "index" notes that link out to everything on a given theme, updated whenever I add something relevant. This is the one that lasted, because the indexes are cheap to maintain incrementally and expensive to let rot, which means I actually keep them current.

What goes in, and what doesn't

Not everything deserves a permanent note. My rule of thumb: if I can imagine a future version of myself searching for this specific thing, it goes in. If it's just processing — thinking out loud to get to a decision — it stays in the daily scratch file and gets deleted eventually. The distinction took a long time to internalize, and getting it wrong in the "save everything" direction is how most knowledge bases become too noisy to trust.

Why plain files, and what backup actually means here

Plain markdown files in a synced folder sound like a boring choice next to a dedicated note-taking app with its own database, and that's exactly the point. Five years is long enough to have lived through at least two note apps changing their pricing model, one shutting down a sync feature I relied on, and one acquisition that made me nervous about export options before anything had actually gone wrong. None of that touched my notes, because they were never locked inside an app's storage format to begin with — they're files on disk, synced the same way I'd sync any other folder, readable by any tool including a terminal with grep if the fancy app ever disappears.

"Backup" for this system is unglamorous: the sync folder replicates across three machines, and a separate nightly job pushes a compressed snapshot to cold storage I don't otherwise touch. The whole job is about six lines of shell:

#!/usr/bin/env bash
set -euo pipefail
DEST="/mnt/cold-storage/notes-backups"
tar czf "$DEST/notes-$(date +%F).tar.gz" ~/notes/
find "$DEST" -name 'notes-*.tar.gz' -mtime +90 -delete

I tested the restore path exactly once, after accidentally deleting a month of notes with a bad find-and-replace script, and the fact that it worked without drama is the single best argument for keeping the whole system this boring.

Linking versus searching

I used to believe dense bidirectional linking between notes was the whole point of a tool like Obsidian. Five years in, I rely on full-text search far more than I rely on links. Links are genuinely useful for the handful of concepts that show up constantly (my recurring architecture principles, a few running lists), but for most notes, a good title and consistent terminology does more for retrieval than a web of manually maintained connections that I'd otherwise need to keep updating forever.

What I'd tell someone starting today

Don't build the system before you have the habit. I spent an embarrassing amount of year one designing folder hierarchies and metadata schemas for a knowledge base that had twelve notes in it. The structure that eventually worked only became obvious after I had a few hundred real notes to look at and ask what was actually making retrieval hard. Start with the dumbest possible setup — one folder, markdown files, a search bar — and only add structure in response to a specific retrieval failure you've actually experienced. Everything else is premature organization dressed up as productivity.

The one habit that mattered more than any tool choice

Writing a note takes willpower in the moment and pays off months later, which is exactly the kind of trade-off humans are bad at honoring. The thing that made it stick wasn't a better app, it was a standing weekly fifteen-minute block where I skim the past week's notes and fold anything worth keeping into the permanent indexes. That one recurring habit has done more for the system's usefulness over five years than any feature of any tool I've tried.

About the author


Staff writer, hardware and tools

Anders Vik spent six years fixing water-damaged laptops and overclocked gaming rigs at a repair shop in Austin before deciding he'd rather write about hardware than solder it for strangers all day. He owns more keyboards and spare NAS drives than furniture, and he tests most of what he covers on his own desk before writing a word about it. He joined Stacklog to cover the hardware and daily tools that change how a workday actually feels.

More from Anders