A note-taking system that survives app death

A note-taking system survives app death when the notes live as plain text files in folders you control, not inside one app's database. If the editor disappears tomorrow, your files are still there, still readable, still openable by the next tool. The trick is to keep the durable part (the files) separate from the disposable part (the app), so no single vendor's collapse takes your notes with it.

This post lays out a concrete note-taking system built on that idea: how to arrange folders, name files, link notes, search, and back up so the whole thing keeps working no matter which app you open it in. Noteline is one editor you can point at these files, but the point of a good system is that the editor is replaceable.

What does it mean for a note-taking system to survive app death?

Apps die in ordinary ways. A company gets acquired and sunsets the product. A subscription lapses and exports stop working. A format changes and old notes won't import. A sync server goes offline and the local copy was never the source of truth. None of these are dramatic. They are the normal lifecycle of software.

Your notes should not share that lifecycle. The fix is to separate two things people usually bundle together:

• The store: where your notes actually live. This should be plain files on a disk you control.
• The reader/writer: the app you use to view and edit them. This is interchangeable.

When the store is plain text and the reader is interchangeable, app death stops being an emergency. You close one app and open another over the same folder. Nothing migrates because nothing moved.

A note-taking system built on a proprietary database fails the opposite way: the notes and the app are the same thing, so when the app goes, the notes go with it. Keeping the two apart is the whole point of local-first software: the data outlives the program that happened to display it.

Why plain text files instead of a database?

Plain text in Markdown (.md) is the most durable format you can write notes in. It is human-readable without any software, supported by thousands of tools, and small enough to keep forever. A .md file from 2010 opens fine today, and a .md file written today will almost certainly open in 2040.

Markdown also fits how we write now, because so much of what we write starts as AI output, and AI assistants tend to output Markdown. When a model hands you headings, lists, and tables, you are already holding the format your note system should use. There is no conversion step and no fidelity loss. (More on that in why plain Markdown files win.)

Here is the trade-off. Databases give you things plain files don't: typed fields, instant relational queries, multi-user editing, and rich embeds. If you need a shared team wiki with permissions and live collaboration, a database-backed tool is the right call. A plain-file system trades those features for permanence and portability. For a personal knowledge base meant to last decades, that is usually the right trade. For a 12-person product spec with comments, it isn't.

How should I structure the folders?

Keep it shallow and obvious. Deep folder trees feel organized for a week and become a maze by month three, because you forget which branch you filed something under. A flat or near-flat structure with good file names beats a deep hierarchy almost every time.

A simple, durable layout:

notes/
  inbox/          # unsorted, gets cleared weekly
  daily/          # one file per day: 2026-06-17.md
  projects/       # one file or one subfolder per active project
  reference/      # things you look up, not things you do
  archive/        # done and dormant, moved here, never deleted
  attachments/    # images and PDFs referenced by notes

Five or six top-level folders is plenty. The rule that keeps it durable: folders are for broad buckets, file names carry the detail. When you find yourself making a folder with one file in it, that is a sign the detail belongs in the file name, not the tree.

inbox and archive do the heavy lifting. New thoughts land in inbox so you never stall deciding where something goes. Finished work moves to archive instead of being deleted, so your active folders stay small and your history stays intact.

How should I name files?

File names are your most reliable index, because they show up in every file browser, every search tool, and every backup, with no app required. Spend your effort here.

A naming pattern that holds up:

Note type	Pattern	Example
Daily note	YYYY-MM-DD.md	2026-06-17.md
Meeting	YYYY-MM-DD-topic.md	2026-06-17-pricing-review.md
Project	project-name.md	noteline-launch.md
Reference	topic.md	markdown-syntax.md
Evergreen idea	descriptive-title.md	notes-should-outlive-apps.md

A few rules keep names searchable and sortable forever:

• Use ISO dates (2026-06-17), so files sort chronologically by name alone.
• Use lowercase and hyphens, not spaces, so names survive every operating system and URL.
• Put the most distinctive word early, so type-to-find lands fast.
• Avoid app-specific characters and emoji in names; they break on some systems.

Good names mean you can often find a note in your file browser before any note app finishes loading.

How do notes link to each other without an app?

Links are where people worry most about lock-in, because linking feels like an app feature. It doesn't have to be. The durable way to link notes is to reference them the way Markdown already does: by file name.

See [pricing review](2026-06-17-pricing-review.md) for the numbers.
Related: [[notes-should-outlive-apps]]

Two conventions both work and both survive app death:

• Standard Markdown links point to a file path: [label](filename.md). These render as clickable links in most Markdown tools, and they stay readable as plain text where they don't resolve (some web renderers won't follow a local file path, and GitHub rewrites them).
• Wikilinks wrap a file name in [[double brackets]]. Many note apps resolve these into clickable links and back-references. An app that doesn't understand them leaves the text intact and readable, so you lose convenience, not data.

The caveat: back-references and a graph view are app features. If your editor builds a graph from your links, a new editor might not, or might build a different one. That is fine. The links themselves are plain text inside your files. The visualization is a convenience layered on top, and conveniences are allowed to be disposable as long as the underlying data isn't.

How do I search notes that aren't in an app?

Full-text search over plain files is fast, universal, and outlives every app. Because your notes are text on disk, the operating system and command-line tools can search them with no note app involved.

• On macOS, Spotlight indexes .md files and finds them by content once they are indexed.
• On Windows, File Explorer search finds files by name; searching inside .md content usually means adding .md as a plain-text extension in the indexing options first, since it isn't content-indexed by default.
• On any system, grep -ri "search term" notes/ searches every note in the folder tree instantly.
• Most note editors add their own fast in-app search on top, which is nicer day to day but not required.

This is the practical upside of a file-based system: you are never one app away from being unable to find your own notes. Worst case, you open a terminal and the notes are still searchable.

How do I back up so nothing is ever lost?

Because notes are files, backup is a solved problem you already have tools for. The note app doesn't need to participate at all.

• Sync folders: put the notes folder in iCloud Drive, Dropbox, or OneDrive. Edits propagate across machines, and many of these keep some version history, depending on your plan and its retention window.
• Git: for the technically inclined, a Git repo gives you a full, diff-able history of every change and a remote copy. Markdown diffs cleanly because it is text.
• Syncthing: peer-to-peer sync with no cloud company in the middle, if you would rather not trust a provider.
• A plain copy: drag the folder to an external drive once a month. Unglamorous and reliable.

A reasonable setup is one sync provider for everyday continuity plus one independent copy (a drive or a Git remote) for safety. Two mechanisms that fail for different reasons rarely fail at once. And because every copy is just files, restoring is dragging a folder back, not running an import.

Why "boring" is the best note-taking system feature

The instinct is to reach for the powerful, feature-rich tool. But power usually comes from proprietary structure, and proprietary structure is exactly what binds your notes to one vendor's fate. A boring system, plain files in plain folders with plain names, has no single point of failure to lose.

That is what makes it hard to break. Each part is independently replaceable:

• Don't like your editor? Open the same folder in a different one.
• Worried about a sync provider? Swap it; the files don't care.
• Want a graph view, or to drop one? Add or remove the app; the links stay text.
• Changing operating systems? Text files move without translation.

Nothing in that list requires an export, a migration, or a vendor's cooperation. The system keeps working because there is no clever part to break.

Where does an editor like Noteline fit?

The system above is the durable layer. You still want a pleasant place to write, and that is the role an editor plays: the part you can swap out without touching the files underneath.

Noteline is built to be that kind of editor. It opens a folder of .md files you already have and shows a live preview as you type, with headings, tables, code blocks, and Mermaid diagrams rendering in place. It adds nothing proprietary to your folder, so your notes stay as .md files anything else can read, and you can leave whenever you want. That fits a system meant to outlast any single app, which is also why it is a one-time purchase rather than a subscription.

You can try the free web editor on a folder of notes and watch the files stay exactly where they were.

The one rule to remember

If you take one thing from this: keep your notes as plain text files in folders you control, and treat every app, including this one, as a guest. Structure shallow, name files well, link by file name, search with the tools you already have, and back up with sync plus one independent copy.

Do that, and app death stops being a threat. It just means opening a different editor over the same folder and getting back to writing.