There is a pattern worth paying attention to among genuinely high-output people. They are not usually running the latest productivity app everyone is talking about. They are running something that looks, from the outside, almost boring. A folder structure that hasn’t changed in years. A text file that keeps getting longer. A spreadsheet with no formatting, just rows. The app almost doesn’t matter. The system underneath it does.
This is not nostalgia for old tools. It is a recognition that productivity software is a volatile market where companies pivot, get acquired, or simply shut down with weeks of notice. Notion, Evernote, Wunderlist, Basecamp (multiple times), Todoist, Bear, every major player in this space has either changed dramatically or disappeared. Users who built their working lives inside a single application’s proprietary structure paid a real price every time. Users who built systems that happened to live inside an application barely noticed the disruption.
The Difference Between a Tool and a System
A tool does something when you use it. A system produces consistent outputs regardless of which specific tool is holding the data. This is a meaningful distinction. When Wunderlist shut down in 2020 after Microsoft absorbed it into To Do, users who had been managing projects through it fell into two camps. One group lost their workflows. The other group exported their data in under ten minutes, imported it elsewhere, and continued working. The difference was not technical skill. It was whether they had been using a tool or had built a system that Wunderlist was temporarily hosting.
Systems have a few recognizable properties. They are built around plain text or widely-supported formats wherever possible, because plain text is the most portable data format in existence and has been for fifty years. They separate structure from content, meaning the organizational logic (folders, tags, naming conventions) is documented somewhere and can be rebuilt in any environment. And they have a clear capture-to-action pipeline: a defined way that new information enters the system, gets processed, and either becomes an action or gets archived.
That last part is where most people break down. They capture everything and process nothing. The inbox becomes the system, which means it’s not a system at all.
How Power Users Actually Configure Ordinary Software
Take email, the application most people treat as a pure inbox-and-reply tool. A power user configures it completely differently. Filters and rules do the initial sorting automatically, handling newsletters, receipts, and notifications before a human ever touches them. The inbox becomes a decision queue, not a storage location. Every email that requires action gets a label or moved to a folder that maps to a project, not a person or a date. Nothing lives in the inbox after it’s been read.
This isn’t magic. It’s a deliberate configuration layer on top of Gmail or Outlook or Fastmail that encodes a decision process. You could move this exact structure to any email client in an afternoon. The client is irrelevant. The logic is the asset.
The same principle applies to note-taking. Obsidian users who have thought carefully about this tend to use a system called PARA (Projects, Areas, Resources, Archives), developed by Tiago Forte, because the categories map to how work actually flows rather than how topics are organized. A note is either tied to an active project with a deadline, a broader responsibility that has no end date, a reference you might consult, or something finished. Those four buckets apply equally in Obsidian, Notion, Bear, Apple Notes, or a directory of plain text files. People who understand this migrate between note apps in an afternoon. People who built elaborate nested tag hierarchies inside one app have created a system that only works there.
The deeper habit is documenting your own configuration. Power users treat their tool setups like code. They write down what their folder structure is and why. They keep a changelog of rules they’ve added to their email filters. When they change something, they update the documentation. This sounds like overhead, but it means the system survives not just app migrations but also their own memory. You can return to a project after six months and reconstruct exactly where everything is because past-you left a note.
Portability Is a First Principle, Not an Afterthought
The instinct most people have when they find a tool they like is to go all-in. Learn every feature. Use the proprietary blocks, the custom database types, the integrations. This is understandable but it’s backwards. The more deeply you nest yourself in a single application’s specific way of representing data, the more expensive the exit becomes. Tech companies bury their best features in settings partly because feature depth creates stickiness, and stickiness is a business objective, not a usability one.
Portability as a first principle means you ask, before adopting any workflow, what happens to this if the app goes away. Can I export this? In what format? Can a script transform that format into something another app accepts? If the answer is no, that workflow doesn’t belong in your core system. It might exist as a convenience layer, but the actual records live somewhere exportable.
Plain text files satisfy this requirement trivially. Markdown satisfies it almost as well and adds light formatting. SQLite databases are a single file, widely supported, and can be queried with any number of tools. CSV is ugly but universal. The formats that fail the portability test are usually proprietary binary formats, closed-API cloud-only storage, and anything described as a “workspace” that has no export function.
The Habit Layer That Most Productivity Advice Skips
Configuration gets you maybe forty percent of the way. The rest is behavioral. A well-designed system that you don’t use consistently is just an elaborate way of feeling organized without being organized.
What separates power users from people who have merely read about productivity systems is a small number of recurring rituals that keep the system current. A weekly review, twenty minutes at most, that processes anything that accumulated in capture inboxes during the week and updates project lists to reflect what actually happened. A daily startup routine that translates “what needs to happen today” into a short, specific list, not pulled from a backlog but derived from an actual assessment of what matters given current context.
These aren’t novel ideas. David Allen described the weekly review in Getting Things Done in 2001. What’s underappreciated is why the ritual matters even when nothing significant happened that week. The act of regularly reviewing the system is what keeps you trusting it. When you trust the system, you stop carrying the mental overhead of trying to remember everything, which is where most of the cognitive load of modern knowledge work actually lives.
The apps will keep changing. New categories will emerge with slightly different takes on the same underlying problems. Some of them will be genuinely better than what came before. None of that matters if your entire working method is entangled with a specific vendor’s implementation. Build the system first. Let the tools be interchangeable.
