Security & privacy

Excellent is local-first, which changes the whole security story: there's no tenant to breach and no upload to intercept, because your operation lives in one database file on your own machine.

What stays local

By default, nothing leaves your computer. Your tasks, leads, candidates, documents, and activity are rows in a local SQLite file you own. We never hold that file, so we can't lose it, sell it, or be compelled to hand it over.

How secrets are protected

Connecting Excellent to outside services means handling access tokens and API keys — and those never sit in the database as plain text:

• Integration credentials are encrypted at rest with AES-256-GCM.
• The master key lives off the database — in your OS keychain, an environment variable, or a key file — so a copy of the database file alone can't unlock them.
• Transport secrets (for sending email or SMS from the CRM, for example) live in environment variables, never in the database.

Tamper-evident by design

Excellent keeps an append-only, hash-chained log of what happened, and can produce signed audit checkpoints over it — a tamper-evident record that the history hasn't been quietly rewritten. Access is governed by a capability model (roles, grants, and per-record permissions) rather than an all-or-nothing login.

Usage analytics are opt-in

There is a thin, opt-in, anonymous rail that can report which features get used to a central sink — the model most tools use to understand adoption. It's fail-closed on two counts: it does nothing unless you've opted in and a sink is configured. A strict allowlist scrubber drops any event that isn't explicitly declared, and identifiers and money values are on an absolute denylist, so record contents can never ride along. You can read exactly what it would send on the in-app transparency page.

Team workspaces, accounts, and auth are separate concerns from this analytics rail — enabling analytics never enables them, and vice versa.