Local-first, offline and no-account are one design decision, not three features

A household organizer knows a surprising amount about how your family actually lives: when you travel, what you own, who your emergency contacts are, which services you pay for. FamilyBoard’s answer is architectural, not just a policy promise: household records use Dexie over the browser’s IndexedDB, and the App routes do not load GA4 or advertising code. There is no FamilyBoard login, household cloud database or sync API receiving a second copy. The browser still fetches the App’s own HTML, JavaScript and updates from the website while online, and the status row sends a same-origin HEAD request with no household fields to check whether the site is reachable; none of those application requests contains the household records stored in IndexedDB.

What “no account” means in practice

Opening the app for the first time shows one form: a home name and, optionally, a comma-separated list of household members. Submitting it creates a household record and writes it to the local database immediately — there’s no email verification step, no password to set, and no server round-trip. The onboarding screen’s own heading says it plainly: “Set up your home without creating an account.” The top bar of the running app carries a permanent reminder of the same fact: “Local data · no app analytics.”

What “offline” means in practice

FamilyBoard is a Progressive Web App with a service worker and a web manifest declaring a standalone display mode. Once the service worker reports that the offline App cache is ready, the core screens keep working without a network connection because every household-record read and write goes to IndexedDB rather than a remote API. The App asks the browser for persistent storage on startup and exposes the request again in Settings when it has not been granted. The browser decides whether to grant it; the setting lowers automatic-eviction risk but does not protect against deliberate site-data clearing, profile deletion or device failure.

What “local-first” means for backup, concretely

Because there’s no server copy, backup is not an optional extra — it’s the only recovery path if a device fails or browser storage is cleared. Settings can export a full JSON backup of every record, optionally encrypted with a password using PBKDF2-SHA256 key derivation at 310,000 iterations and AES-256-GCM encryption — real, named cryptographic primitives, not a marketing claim. Restoring a backup offers merge (add to what’s there) or replace (wipe and restore) modes; choosing replace automatically downloads a safety snapshot of your current data first, before anything is overwritten, so a restore mistake doesn’t destroy data you hadn’t backed up yet.

The bulk-edit path: master CSV

Beyond the JSON backup, Settings also offers a household “master table” — export every record to a single CSV, edit it in a spreadsheet, and import it back in merge or append mode, with a preview step that surfaces validation errors before anything commits. This is the same local-only principle applied to bulk editing: your data leaves the browser only as a file you explicitly download, not as a background sync.

One household per browser profile — the honest limit

The app reads data.households[0] — the first household in the local database — as the household you’re using. There’s no multi-household switcher and no cross-device sync built in: a household created in one browser profile on one device doesn’t appear in another browser or another device unless you export a JSON backup from the first and restore it into the second. That’s the real tradeoff behind “no account”: nothing to log into also means nothing to sync through.

What local-first does not protect against

Local storage isn’t the same as invincible storage. Anyone who can unlock your device and open your browser can potentially see your data, the same as any other locally-stored information — FamilyBoard doesn’t add its own login screen or device-level lock. Use your device’s own passcode and encryption, and treat the encrypted JSON backup’s password as the thing actually protecting an exported file that leaves the device.