Why local-first matters when AI hands you a draft

The unspoken thing about AI-generated drafts is that you're now responsible for content you didn't write. If the model hallucinated a number, you're the one who shared it. If the draft references a competitor by name, your company's compliance team cares. If it's an M&A memo, the stakes are higher than most tools' privacy defaults assume.

Most editors upload from the first keystroke. Google Docs saves as you type. Notion's local cache is a cache; the authoritative copy is in their cloud. Even tools that offer "private workspaces" do so on their infrastructure. For an internal-only AI draft you've not yet reviewed, that default is more aggressive than it needs to be.

What "local-first" means here

In Vela Docs, when you drop a file anonymously, it lives in your browser's IndexedDB. That's a local database scoped to your domain. The file never reaches our servers, our logs, our backups. If you close the tab and clear site data, the file is gone. We have no record it existed.

You can edit it, render it, download the result, and never sign in. The product works fully without uploading. The moment you click Share, you've made a deliberate choice and the file is uploaded so a collaborator can fetch it. That's the only path data leaves your browser.

Why the default flip matters

Compare to the "upload on keystroke" default. There, the decision to leak the document was made by the tool, not by you. You typed; bits left the machine. That's fine for most prose. It's not fine for the cases where bits shouldn't leave the machine at all.

Concrete situations where this default matters:

• An AI summary of a board meeting. You want to clean it up before sharing with the board. Uploading the first draft to any cloud tool puts a pre-review version on someone else's servers, even if you delete it later.
• A draft response to a regulator. Legal wants to review before anything's recorded externally. A tool that uploads on the first keystroke is the wrong tool.
• An M&A memo, a comp plan, a layoff announcement. The category of "drafts that should never leak even by mistake." A local-first tool respects this; cloud-first tools require you to trust their security posture for a draft you'd rather not have anywhere.
• A founder's pitch deck draft. You don't want it on a competitor's customer list 6 months from now if some indexing service decides your file was indexable.

The technical bit

IndexedDB is the browser's own structured storage. Same-origin policy means only the page that wrote the data (docs.vela.partners) can read it back. Other tabs, other sites, our analytics, none of them can see your file. You can verify this in DevTools: Application → IndexedDB → files-vela. That's where your draft lives until you act.

When you click Share, we POST the file to Firestore over HTTPS, with the explicit Authorization header carrying your Firebase ID token. That request is the first time the file leaves your machine. It's also when we start logging anything at all about it.

What we don't do

We do not train AI on your files. We do not use your drafts for product analytics. We do not have any telemetry that fingerprints individual users. Theprivacy pageand thesecurity pageare the long version of this paragraph.

When local-first stops mattering

Not every draft is sensitive. A meeting agenda, a personal essay, a fun ChatGPT one-pager: upload-on-share and upload-on-keystroke look the same for those. Where it matters is the long tail of cases where the right answer is "I'd like to look at this before anyone else does," and that's where the default flip pays off.

One short takeaway

AI generates more drafts you're not sure should leave your machine. Local-first storage makes leaving your machine an explicit action rather than the default.