Why Local-First Is Right for Finance Apps - And Why Sync Is the Hard Part
Local-First Is Right for Finance Apps
When someone sniffs Splitwise traffic with Wireshark and finds their financial data flowing through third-party servers unencrypted, the obvious response is to build a local-first alternative. And local-first is absolutely the right move for finance apps. Your transaction history, account balances, and spending patterns should live on your device, under your control.
But there is a catch: multi-device sync.
The CRDT Problem for Financial Data
Conflict-free replicated data types (CRDTs) work beautifully for collaborative text editing and todo lists. But financial data has properties that make CRDT-based sync significantly harder:
- Transactions must be ordered - the sequence of debits and credits matters for running balances
- Rounding errors compound - if two devices split a bill slightly differently due to floating point, the discrepancy grows over time
- Deletions are dangerous - in a regular CRDT, deleting and re-adding an item is fine. Deleting and re-adding a payment can cause double-charging
Regular CRDT merge strategies assume that conflicts can be resolved automatically. For financial data, some conflicts require human judgment - "did you really pay this bill twice or is this a sync artifact?"
What Works
The practical approach is to use CRDTs for the metadata layer - tags, categories, notes - while using a stricter consensus protocol for the actual financial transactions. This gives you the flexibility of local-first for most operations while maintaining correctness where it matters.
This same principle applies to desktop agents handling financial workflows. An AI agent that automates expense tracking or invoice processing needs to understand that financial operations require stronger guarantees than file management or calendar scheduling.
Fazm is an open source macOS AI agent. Open source on GitHub.