Local-First and Encrypted: Building Apps That Cannot Leak

"We do not look at your data" is a policy. Policies change, companies are acquired, and databases get breached. An architecture where the data never reaches you is a different kind of claim, because it does not depend on anyone's conduct.

For health, finance and anything intimate, that difference is increasingly what users choose on.

What local-first actually means

The device holds the real data. The server, if there is one, holds ciphertext it cannot read. Keys stay on the device, derived from something the user controls and backed by the platform's secure hardware.

The practical test: if your entire database leaked tomorrow, what would the attacker learn? If the answer is "nothing useful", the architecture is doing its job.

The parts that need deciding early

Where the key comes from

A key derived from a user passphrase means you genuinely cannot recover it — which is the point, and also a support burden. A key held in the platform keychain and synced through the user's own cloud account is more recoverable and shifts trust to the platform vendor.

Most consumer apps land on the second, because the first means "forgot password" equals "lost everything", and users do not expect that.

Whichever you choose, decide before launch. It is not a swappable component.

What leaks even when content is encrypted

Metadata. Record counts, timestamps, sizes, sync frequency. For a cycle-tracking or mental-health app, the pattern of writes is itself sensitive even if every value is ciphertext.

Padding record sizes and batching syncs on a schedule rather than on every change reduces what can be inferred. Perfect protection is not achievable; meaningful reduction is.

Search over encrypted data

You cannot query what you cannot read. Search must happen on-device, over decrypted data, which means the device holds the index. That is usually fine — it is also why these apps feel fast.

Backup

Encrypted backup is the feature that makes local-first survivable. Without it, a lost phone is lost data, and users will not forgive that. Encrypt client-side, upload the ciphertext, and be explicit that recovery requires the key.

What you give up

Server-side analytics on content. Server-side processing. Easy debugging — you cannot look at a user's data to diagnose their problem, so error reporting has to be designed to be useful without content.

Cross-device sync becomes genuinely harder, because conflict resolution has to happen on a device rather than centrally.

These are real costs. The trade is worth it when the data is sensitive enough that holding it is a liability rather than an asset.

Say it plainly

If you build this, the claim is a product feature and deserves prominence — but it has to be accurate. "End-to-end encrypted" has a specific meaning, and overstating it is worse than not claiming it, because someone will eventually check.

State what is encrypted, what is not, and what you can see. Users reward that specificity.