The local-first software buyer's guide

"Local-first" has joined the list of words SaaS marketing has tried to take back from the people who meant it. Vendors with a multi-tenant database now ship a desktop wrapper around their web app and call it local-first. Others let you sync to a folder and call that ownership. Some really do mean it.

This is the buyer's guide we wish we'd had when we started looking. It assumes you already know why local-first matters — you want your data on your hardware, you want to keep working offline, you want to leave without an exit project. The question is how to tell which vendor actually delivers that.

What "local-first" should mean in 2026

The phrase comes from Ink & Switch's 2019 essay, which set seven properties — fast, multi-device, offline-capable, collaborative, longevity, privacy, user control. Most working buyers will collapse those down to three:

1. The data is yours, on disk, in a format you can open without the vendor.
2. The app keeps working when the vendor doesn't.
3. Leaving is a copy command, not a migration project.

If any one of those three is missing, it's not local-first. It's a hosted product with a desktop client.

The five questions to ask a vendor

1. Where does the canonical database live?

"In the cloud, mirrored to a cache on your machine" is not local-first — it's a cache. "On your machine, optionally synced to a relay" is. Ask the vendor to name the file. If they can't, you're not buying local-first.

A good answer: "It's a SQLite file at ~/.appname/data.db. You can open it with the sqlite3 CLI. The cloud is optional."

2. What happens when the internet is off?

A real local-first app launches, reads, writes, and lets you finish your work without a network. Sync resumes when you come back. Many "offline-capable" SaaS apps will let you read cached records but refuse new writes — that's not the same thing.

The test is one tab, airplane mode, can you do your job for an hour. If yes, it's local-first. If you hit a "you're offline" toast on the first action, you bought a cache.

3. What is the file format, and is it documented?

The canonical store should be:

• A format you can read without the vendor's binary (SQLite, JSON, Markdown, CRDTs in a known shape).
• Documented, ideally with a schema you can introspect.
• Stable enough that a backup from a year ago still opens today.

Proprietary blob files that only the vendor's app can decrypt are a trap. They give you the illusion of ownership without any of the rights.

4. How do you leave?

This is the question that decides everything else. Read the export documentation before you sign. Look for:

• An export that produces the same shape as the canonical store — not a downgraded CSV.
• No artificial caps ("free plans export 10k rows" is a soft lock).
• No "we hold the export queue for 7 days" — that's the vendor managing a switching cost.

If the vendor is local-first, the answer to "how do I leave" is "copy the file."

5. What runs in the cloud, and is it optional?

Most local-first apps still have a cloud — for sync, search, AI inference, or sharing. That's fine. The question is whether the cloud is optional. Can you run the product entirely on your machine, against your own database, with no network calls? If the answer is "no, AI is server-side," you're back to renting.

It's reasonable for the cloud to be the default. It's not reasonable for it to be mandatory.

Red flags

A non-exhaustive list of things that look local-first but aren't:

• "Desktop app" that is an Electron wrapper around a web view authenticating to a hosted backend.
• "Offline mode" that's a 24-hour read-only cache.
• "On-prem option" that's a six-figure enterprise tier with a deployment engineer attached.
• "You own your data" in a marketing headline, with an "Export to CSV" button as the implementation.
• "End-to-end encrypted" for a product where the keys live in the vendor's HSM.

Any one of these isn't necessarily disqualifying. All of them together are.

Green flags

What we look for, in order:

1. The vendor will tell you the path on disk without being asked twice.
2. The format is open (SQLite, JSON, Markdown) and documented.
3. Sync is optional — the product is fully functional with networking disabled.
4. AI is bring-your-own-key — inference runs against your account, not the vendor's.
5. The roadmap names multi-device sync as additive, not the foundation.

How Excellent answers these

We built Excellent against this checklist. The honest version:

• The database is a SQLite file on your machine. You can open it with sqlite3.
• Every app — tasks, CRM, hiring, documents — reads and writes through the same file.
• The product runs fully offline. Sync is something you opt into; it's not the foundation.
• AI agents run against your own LLM key. Excellent doesn't see your prompts.
• Export is "copy the file." Backup is "copy the file." Migration is "copy the file."

You don't have to take our word for it — every one of those five claims is checkable inside the docs.

What this guide is, and isn't

This isn't a vendor list. It's a checklist you can run a vendor through in fifteen minutes. The right local-first tool for you depends on what work you're doing — but the floor for "local-first" should be these five answers.

If a vendor can't pass the floor, it doesn't matter how nice the rest of the demo was.

---

Next up: if you want to apply the checklist to a specific category, the comparison pages Excellent vs Notion, Excellent vs Linear, and Excellent vs HubSpot score each tool against this exact framework.