Every few months, an author posts in a forum about losing access to their work. A cloud service went down. An account was suspended. A sync conflict corrupted a manuscript. The responses are always sympathetic, but the advice is always the same: keep local backups.
We think the advice should be different. The tool itself should keep your files local.
The Cloud Assumption
The default architecture for modern software is cloud-first. Your data lives on someone else's server. You access it through a browser or a thin client that's really just a window into a remote application. This model makes sense for collaborative tools where multiple people need simultaneous access to the same data — Google Docs, Figma, Notion.
But book writing is not a collaborative real-time activity for most authors. You sit alone with your manuscript. You write, revise, format, and export. The collaboration happens asynchronously — with editors, beta readers, and formatters — through file exchange, not simultaneous editing.
For this use case, cloud-first architecture is not an advantage. It's overhead. You're paying for infrastructure you don't need, accepting latency you shouldn't have, and trusting a third party with the one thing you can't afford to lose: your manuscript.
What You Give Up
When your book lives in the cloud, several things happen that you may not notice until they matter:
- You need an internet connection to work. This sounds trivial until you're on a plane, at a cabin, or in a country with unreliable connectivity. Your own book becomes inaccessible because a server in Virginia is unreachable.
- Your data is subject to someone else's terms of service. Cloud providers can change their terms, raise prices, or shut down. Your data's availability depends on the ongoing viability of a company you don't control.
- Performance depends on bandwidth. Loading a 400-page manuscript over the network is slower than reading it from a local SSD. Every keystroke that syncs to a server introduces latency. This accumulates into a feeling of sluggishness that's hard to pinpoint but impossible to ignore.
- Privacy is someone else's promise. Your unpublished manuscript sits on servers accessible to the company's employees, their infrastructure providers, and potentially their AI training pipelines. You have a privacy policy. You don't have a guarantee.
What Local-First Gives You
Local-first means the application and your data live on your machine. The network is optional, not required. This reversal has several consequences:
- Instant performance. No network round-trips. Your manuscript loads in milliseconds. Typesetting happens on your CPU. The preview renders locally. Everything feels immediate because nothing is waiting for a server.
- Offline by default. You can write and format anywhere, with or without a connection. The tool doesn't degrade gracefully without internet — it simply works the same way it always does.
- Data sovereignty. Your files live in a directory on your machine. You can back them up however you want — Dropbox, iCloud, an external drive, a git repository. You're not locked into a proprietary sync system.
- No subscription dependency. If we disappear tomorrow, your data doesn't disappear with us. The files are on your disk. The exports are standard PDF and EPUB. Nothing about your work depends on our continued existence.
Why We Built a Desktop App
Cambric is built with Tauri, a framework for building native desktop applications. It's not a browser tab pretending to be an app. It's not a PWA that sort of works offline if you remembered to cache the right service worker. It's an actual application that installs on your computer and runs without a browser.
The typesetting engine runs natively on your machine. The file system is your file system. The export writes directly to your disk. There's no upload step, no sync step, no "waiting for cloud" indicator. The entire pipeline, from manuscript to finished PDF, happens locally.
This is a deliberate choice with tradeoffs. We can't offer real-time collaboration. We can't show you your manuscript on your phone without building a separate app. We can't do automatic cloud backup without you choosing a sync service.
We think those tradeoffs are correct for this use case. The book you're writing is the most important file on your computer. It should act like it.
Your manuscript is not content to be managed. It's a file to be owned. The tool that handles it should respect that distinction.