The app should be optional

There is a test worth applying to any tool that holds your work. Delete the application. Is the work still there, in a form something else can open?

Most software fails it. Notes live in a proprietary database, or in a cloud account that is only reachable through the client that wrote it. The data is not gone, exactly, but retrieving it requires the vendor's continued cooperation — and that is a different thing from owning it.

Files first, features second

Passing that test is a format decision, and it has to be made before anything else, because every subsequent feature either respects it or quietly breaks it.

Ampersand keeps every document as plain Markdown in a folder you choose. Cali writes .cal text files that open in any editor. Pastry keeps clipboard history in local SQLite — not a service format, a database file on the machine. In each case the application is a way of working with the data rather than the only way of reaching it.

• ●The format is readable without the app, by a person or another program.
• ●The storage location is the user's choice, not an opaque container in a support directory.
• ●Nothing about the format assumes the vendor still exists.

What it costs

This is not free, and pretending otherwise is how the decision gets reversed six months in.

Plain files give up cheap relational queries. Block-based editing over a flat Markdown file means reconstructing structure on every load rather than reading it out of a schema. Version history has to be built rather than inherited from a sync service. Full-text search over a directory is slower than a query against an index you control completely.

Each of those is solvable, and each takes real engineering. The payoff is not performance — it is that the format outlives every decision made around it, including the decision to stop building the app.

Why Rust, and why not Electron

Local-first raises the bar on the runtime, because the work now happens on the user's machine rather than on a server you can scale. Parsing, indexing, diffing, and search all run in the foreground of an application someone expects to open instantly.

Tauri with a Rust core keeps the heavy work native and the interface in the web stack, which is a reasonable division: the parts that need to be fast are fast, and the parts that need to be iterated on stay iterable. A bundled browser engine per app is a lot of memory and startup time to pay for a rendering layer the OS already has.

In Cali the argument goes further. The expression engine — lexer, parser, evaluator — is hand-written with no math library behind it, because the product is reading ordinary sentences rather than formal expressions. A general-purpose dependency would have made the ambiguous cases someone else's default instead of a design decision.

Sync is a feature, not a foundation

The usual objection is that people expect their work on every device, and they do. But there is a difference between building sync on top of local files and building an application on top of sync.

Local-first means the app is fully functional with the network off, and synchronisation is an optional layer that moves files around. Cloud-first means the network is a dependency of opening a document. The first degrades gracefully on a plane; the second shows a spinner.

It also changes the privacy conversation from a policy into an architecture. Clipboard history is a good illustration: it contains passwords, tokens, and private messages, and Pastry keeps it in local SQLite with no account and no server. That is not a promise about how data is handled — it is a statement that the data never left.

The test again

Delete the app. If the work is still there and still readable, the format was the product and the application was a good interface to it. If it is not, the application was the product and the work was hostage to it.

Both are legitimate businesses. Only one of them is something you can recommend to someone who intends to still have their notes in twenty years.