Why Local-First — Frame's Architecture

The first decision in designing Frame was the data architecture. "Where should a manuscript live?" is both a technical and a philosophical question.

The cloud's appeal

For a team building a SaaS, cloud storage is a natural default. Sync, collaboration, backup, billing — everything gets easier. But Frame's users aren't general users; they're writers. To a writer, a manuscript is a confidential document, a work nobody should see until it's finished.

One project, one file

One project is one .frame file on your disk. Copy it to an external drive and it moves. AirDrop it. Drop it in Dropbox. Print it and put it in a safe.

• Benefit 1 · Full data ownership. Independent from the company.
• Benefit 2 · Complete offline functionality. AI only when needed.
• Benefit 3 · Backup is trivial — a file copy.
• Drawback · Real-time collaboration is hard. We work around it via export/import.

How the AI works

When you use an AI feature, the relevant paragraph or chapter is sent through Frame's Hub to Google Gemini. It is deleted immediately after the response is generated, and is never used for training. The Hub only relays requests and aggregates token counts; it does not store manuscripts.

Local-first is not a technical choice. It is a promise of trust.

Challenges ahead

Real-time collaboration, a mobile reader, family sharing — we need to implement all of these while preserving the local-first principle. We're experimenting with CRDTs, opt-in Hub sync, and end-to-end encryption. It will take time, but we will not abandon the principle.