How to Build a Personal Knowledge Management System That Actually Sticks

I’ve built and abandoned more note-taking systems than I can count. Evernote, then Notion, then Obsidian, then a brief and embarrassing detour into a folder of plain text files I never opened again. Each time I told myself this was the one. Each time I quit within a month.

The thing that finally stuck wasn’t a better app. It was admitting that most PKM advice is written by people who enjoy building systems more than using them. I was one of those people. If you’re reading this, you probably are too.

So let me save you a few years. Here’s what actually worked for me, and why the usual advice fails.

Most PKM systems die for the same reason

They demand too much upkeep relative to the value they return early on.

Think about what a new system asks of you on day one. You have to pick a tool, learn its quirks, design a folder structure, decide on tags versus links, set up templates, and then — the part nobody warns you about — migrate your existing mess into it. That’s a weekend of work before you’ve captured a single useful thought.

Then you use it for two weeks, and the payoff is… a handful of notes you could have found with a search anyway. The maintenance cost is constant. The benefit is delayed and uncertain. Of course you quit. Any rational person would.

The systems that survive are the ones where the cost shows up immediately and the benefit shows up immediately too. Not in some imagined future where you’ll be “building a second brain” and connecting ideas across domains like a genius. Today. This week.

Start with one problem, not a philosophy

Every PKM guide starts with a grand vision: capture everything, connect everything, build a knowledge graph that mirrors your mind. This is backwards.

You don’t need a system. You need to solve one annoying problem. Pick the most concrete one you actually have right now:

• You keep forgetting decisions you made on a project and why you made them.
• You read books and retain nothing.
• You have ten half-finished ideas for side projects and can’t keep track.
• You keep re-solving problems you already solved six months ago.

Pick exactly one. Build the smallest possible thing that fixes it. Ignore everything else.

When I started, my problem was that I kept re-learning the same technical gotchas. I’d hit a weird bug, figure out the fix, and then hit the same bug four months later with no memory of the solution. So I made one rule: when I solve something non-obvious, I write it down in a single file. That’s it. No folders, no tags, no graph view. One file, appended to forever.

That file has been useful roughly a hundred times. It’s ugly and disorganized and I love it.

Pick a tool you’ll still open in six months

Here’s my unpopular opinion: the tool barely matters. What matters is friction.

The best tool is the one that’s already open, or one keystroke away. For me that’s a plain text editor with a global hotkey. For you it might be Apple Notes, or a paper notebook, or something fancier. I don’t care, and neither should you.

What I’d avoid:

Tools that require you to think about the tool. If you spend your capture time deciding which folder a note goes in, you’ve already lost. The capture step should take under ten seconds.

Tools you’re using because a YouTuber uses them. Obsidian is great. It’s also a rabbit hole of plugins and graph views that will eat your weekends. I know because it ate several of mine. If you enjoy that, fine — but be honest that you’re doing it for fun, not for productivity.

Anything that locks your notes in a format you can’t read with a text editor. Your notes should outlive the app. Plain text or Markdown is the safe bet. I’ve migrated my notes across four tools now and the plain ones always survived.

The specific tool is a detail. The habit is the product.

Capture cheap, process rarely

The classic advice is “capture everything, then process it later in a weekly review.” I’ve found the capture part is right and the process part is mostly theater.

Capture should be trivially easy. A thought hits you, you write it down in one place, you move on. No deciding, no organizing. If you have to think, you won’t do it.

Processing, though, is where most systems collapse. The weekly review sounds disciplined. In practice it becomes a guilt pile. You skip one week, then two, then the pile is so big you never touch it again.

My approach: don’t process on a schedule. Process when you need something. When I’m writing or starting a project, I search my notes. If a note is useful, it gets pulled into the work. If it’s not, it sits there. That’s fine. An unread note costs nothing. A guilt pile costs your motivation.

Some people genuinely thrive on a weekly review. If that’s you, keep it. But if you’ve tried it three times and bounced off, stop pretending you’re that person.

Let the structure emerge

Everyone wants to design the perfect folder hierarchy up front. Don’t. You don’t know what your notes will look like yet.

Start flat. One folder, or no folders. Add structure only when the lack of it actually hurts — when you can’t find something and search isn’t cutting it. That’s your signal to add one folder, or one tag, or one naming convention. Not before.

I added my first real tag about eight months in. I added a second one a year later. My system looks almost nothing like what I would have designed on day one, which is exactly why it works. It grew to fit my actual use instead of my imagined one.

This is the part where PKM enthusiasts will tell you that you’re missing out on the magic of linking notes and discovering unexpected connections. Maybe. In a decade of doing this, the number of times a serendipitous link between two old notes produced something valuable is… low. Not zero, but low enough that I wouldn’t build a whole system around chasing it.

Make retrieval the only metric that matters

Here’s the test for any PKM system: can you find what you need, when you need it, in under a minute?

That’s it. That’s the whole game. Not how many notes you have. Not how pretty your graph looks. Not whether your system would impress someone on Twitter.

If you can’t find things, your system has failed no matter how much you’ve captured. If you can find things, it’s working even if it’s a single messy file.

This is why I lean on search over folders and tags. Search doesn’t require me to remember where I put something. I just need to remember roughly what I wrote, which I usually do. Folders require me to remember my own past decisions, which I almost never do.

When to quit and rebuild

Sometimes a system really does need to die. If you’ve gone a month without opening it, that’s a signal. But before you burn it down and start over, ask why it died.

Usually it’s not the tool. It’s one of these:

• You made capture too hard.
• You built structure you didn’t need yet.
• You turned it into a chore with a review process you resent.
• You optimized for the imagined future instead of the present problem.

Fixing any of those is cheaper than migrating to a new app. I’ve learned this the hard way, several times.

What I actually do now

Since I’ve been vague, here’s the concrete version. It’s unglamorous.

I have one plain text file for technical gotchas, appended to forever. I have a folder of Markdown notes, one file per idea, named with a date and a few words. I have a scratch file for things I want to remember to look up. I search all of it with a single tool. I have no tags, no graph, no daily notes, no templates.

It took me about a decade to arrive at something this boring. That’s the joke. The system that sticks is usually the one that looks like you didn’t build a system at all.

FAQ

Do I need a specific app? No. Pick something with low friction and plain-text storage if you can. The app is the least important decision you’ll make.

What about linking notes and building a knowledge graph? It’s fun. It’s rarely as useful as it’s sold. Try it if you enjoy it, but don’t let it become the point.

How many notes should I have? Wrong question. Ask how many you can find when you need them.

Should I do a weekly review? Only if you actually enjoy it. If you’ve quit it before, you’ll quit it again.

My system keeps dying. What do I do? Stop rebuilding. Find the one step that’s too hard and make it easier. Usually that’s capture.