Why Plain Text Wins

Every productivity app asks you to pour your day into its database. Plain text asks a different question: what if the file came first?

This is not a nostalgia piece. I'm not arguing for plain text because it's retro, or minimalist, or because real developers use terminals. I'm arguing for it because it's the only task-management format that has never stranded anyone — and in an industry where apps die, pivot, and price themselves out of existence every few years, that's not a minor detail. It's the whole ballgame.

The problem with app-owned data

Most task managers store your work in a proprietary format behind an API. You can export — maybe — but you can't open your task list in another editor, grep it from the terminal, or version it with git. The app owns your data, and you rent access to it.

That rental agreement is the hidden cost of every modern to-do app. You don't see it on the pricing page. You see it the day the app shuts down, pivots to AI chat, or raises its price past your tolerance. Your workflow goes with it. You start over in the next app, re-entering the same tasks, rebuilding the same projects, losing the history of what you actually shipped.

This isn't hypothetical. I've lived through at least four "irreplaceable" productivity tools dying or gutting themselves — and the pattern is always the same. First the roadmap goes quiet. Then the acquisition. Then the email: "We're sunsetting the product. Your data can be exported as JSON until March." And you realize you've been maintaining someone else's business model with your most valuable resource: your attention, organized into a system you'll now have to rebuild.

What file-first means in practice

A .todo file is a plain text file. That sentence sounds boring. It's actually the most powerful property a task system can have:

• You can open it in any editor. Ever. In 2036, there will still be text editors. There may not be a certain task app.
• You can search it with grep. Your task list becomes queryable — a decade of decisions, findable in milliseconds.
• You can back it up by copying it. No export ceremony. Copy the file to a USB stick, a Dropbox folder, a git repo. Done.
• You can sync it with whatever you already use. iCloud, Nextcloud, Syncthing, a git remote — the file doesn't care. It has no opinions about your infrastructure.
• You can version it. Every plan becomes history. "What did I actually do in March?" is one git log away.

Plainlist reads that file and gives you a richer view: focus mode, planning, habits, goals. But the file is always the source of truth. If you delete Plainlist tomorrow, your tasks are still right there — readable, editable, yours.

That last sentence is the entire product philosophy. Most apps would consider it a weakness to admit. I consider it the only feature that matters.

Why this matters more than features

Features come and go. The file stays.

Think about what you're actually betting on when you choose a task manager. Every tool decision is a bet on how long that tool will last. Feature-rich apps are betting that their feature set will keep you locked in — that the switching cost you've accumulated will outweigh your frustration. Plain text is betting on something more durable: that the format itself is immortal.

And it's a safe bet. Plain text has outlasted every proprietary format ever created. It outlived WordPerfect, Lotus 1-2-3, Evernote's dominance, and every task app that ever claimed to be the last one you'd need. Text is the closest thing software has to a bedrock. If a task list is a record of your work — and it is — it deserves the same durability as the work itself.

There's a reason the people who manage the most complex systems in the world — developers, sysadmins, researchers — default to text. It's not because they enjoy ugliness. It's because they've been burned by formats before, and text is the one thing that has never burned them. Every other format is a promise. Text is a receipt.

The counterargument: "plain text is for developers"

This is the objection I hear most, and it deserves a real answer. Plain text, the argument goes, is for people who are comfortable with files, folders, and syntax. Normal people want buttons and colors.

Here's the thing: normal people have been using plain text their whole lives. It's called a notebook. The most successful planning system in human history is a piece of paper and a pen — and paper is just plain text with worse search. The file format isn't the barrier. The barrier is apps that make you feel like you need training wheels, when what they're really doing is making sure you never leave.

The buttons and colors aren't helping people plan. They're helping people avoid planning. A list of forty tasks is not a plan; it's a pile. A plan requires time — the one resource a list doesn't have. The calendar view is the part that works, and you don't need a proprietary database to have a calendar. You need a file, and a tool that knows how to turn it into a day.

The turn: what plain text actually gives you

Here's what I've come to believe after years of watching people (myself included) cycle through apps: most productivity tools fail because they're built to be used, when they should be built to be ignored.

A good system is one you stop thinking about. A text file is the closest thing we have to that. It's the task-management equivalent of a chair that doesn't squeak — you only notice it when it's not there.

But there's a deeper reason plain text wins, and it's not durability. It's ownership. When your system lives in a file, the system is genuinely yours — in a way that a database you rent can never be. You can change it, hack it, extend it, annotate it. You can keep a decade of task history in a folder and know exactly what it is. No app update can rearrange it. No redesign can move your buttons. No pricing change can hold it hostage.

The file is the one part of your productivity stack that will outlive every app you ever use. Everything else is a visitor.

The practical test

If you're skeptical, try this. Take your current task list and ask three questions:

1. Can I open it in any editor right now? Not export it — open the actual file.
2. Can I search it from a terminal? Grep it, version it, script it?
3. If the app vanished tomorrow, would I lose anything?

If the answer to #3 is "yes," you don't own your system. You're renting it — and the rent can be raised at any time, by anyone, for any reason.

Plainlist exists because I believe the third question should always be answered "no." The app should be the layer that makes the file beautiful, not the wall that keeps it prisoner. Write the task as text; watch it land on Tuesday. The file first, everything else second.

Your task list is a record of your work. It deserves the same durability as the work itself.