Local-First And Data Boundaries
Local-first is often the simplest v1 data boundary. It keeps product scope small until users prove they need shared state.
Pick The Boundary
| Boundary | Use when | Upgrade path |
|---|---|---|
| Local files | Users own documents, markdown, CSV, JSON, media | Add index/cache, then sync/export |
| SQLite | Structured local state, search, audit events, sessions | Add backup/export, then sync when needed |
| IndexedDB/cache | Browser/PWA local state and offline behavior | Add server sync only for multi-device needs |
| Device platform storage | Mobile app settings, encrypted secrets, biometrics | Add export and backup before cloud sync |
| Backend database | Shared state, auth, roles, payments, jobs | Add local caches only where offline matters |
Local-First Questions
- Can the user export everything?
- Can the app recover from a corrupt local database?
- Does backup depend on the OS, the app, or the user?
- Is encryption needed at rest?
- Is sync truly v1, or can it be manual import/export?
- What happens when two devices edit the same data?
When A Server Becomes Unavoidable
- Multiple users need the same canonical data.
- Permissions or roles cannot be trusted to clients.
- Payments, webhooks, or external integrations need secret custody.
- Background jobs must run when the user’s device is off.
- Audit logs must be tamper-resistant.