Explore the local-first software movement, from CRDTs to sync engines. Learn why developers are choosing offline-first architecture and how it transforms personal finance apps.
For nearly two decades, cloud computing has dominated how we build software. Every startup pitch deck featured the same architecture: thin client, thick server, data in the cloud. But something interesting is happening. A growing movement of developers, researchers, and companies are questioning this orthodoxy and building software that works differently. They call it local-first software.
This is not a rejection of the internet or collaboration. Instead, it is a fundamental rethinking of where data lives, who owns it, and how applications should behave. For developers building personal software, particularly in sensitive domains like finance, health, and personal productivity, local-first architecture offers compelling advantages that cloud-first approaches simply cannot match.
Local-first software is an approach where your data primarily lives on your device, not on a remote server. The application works offline by default, treats the local copy as the source of truth, and synchronizes with other devices or users when connectivity is available.
This differs from traditional approaches in important ways:
Cloud-first applications store your data on remote servers. The local device is merely a viewport into data that lives elsewhere. When you are offline, functionality is limited or nonexistent. Examples include Google Docs, Notion, and most SaaS applications.
Offline-capable applications can function without internet but still treat the server as the canonical data source. Your local changes are staged until they can be sent to the server. Examples include many mobile apps that cache data for offline viewing.
Local-first applications flip this model. Your device holds the primary copy of your data. You can work indefinitely without network access with no functionality loss. Synchronization is a peer-to-peer operation between devices, not a client-server upload. Examples include Git, Obsidian, and Linear’s sync architecture.
The distinction matters because it changes fundamental assumptions about ownership, availability, and privacy.
In 2019, a research lab called Ink & Switch published a paper that crystallized the local-first vision. Their essay “Local-First Software: You Own Your Data, in Spite of the Cloud” articulated seven ideals for local-first software:
This manifesto resonated deeply with developers who had grown frustrated with the limitations and lock-in of cloud services. It sparked renewed interest in technologies that could make local-first software practical at scale.
The Ink & Switch paper did not invent these ideas. Distributed systems researchers had been working on the underlying problems for decades. But the paper brought academic concepts into the practical software development conversation and gave the movement a coherent identity.
Building local-first software requires solving hard distributed systems problems. When multiple devices can modify data independently without coordination, how do you merge those changes without conflicts? How do you ensure everyone eventually sees the same state?
CRDTs are data structures specifically designed for distributed systems where nodes can modify state without coordination. The key insight is that if you design your data structures carefully, concurrent modifications can always be merged automatically without conflicts.
Consider a simple example: a counter. In a traditional system, if two users both increment a counter from 5 to 6 simultaneously, you have a conflict. Which value is correct?
A CRDT counter works differently. Instead of storing a single number, it stores the increments from each user separately. User A’s increments are tracked independently from User B’s. The current value is computed by summing all increments. If A increments once and B increments once, the total is 7, regardless of the order the operations are received. No conflict, no coordination required.
This principle extends to more complex data structures:
The CRDT research community has developed structures for various use cases: maps, graphs, JSON documents, and rich text. Libraries like Yjs, Automerge, and CRDTs provide production-ready implementations.
CRDTs solve the conflict resolution problem but leave open questions about how changes propagate between devices. Sync engines handle this layer, managing:
Modern sync engines like Replicache, PowerSync, and Electric SQL provide these capabilities as infrastructure that applications can build upon. They handle the complexity of state synchronization while exposing simple APIs for reading and writing data.
The CAP theorem states that a distributed system can provide at most two of three guarantees: Consistency, Availability, and Partition tolerance. Since network partitions are inevitable (your device will go offline), practical systems must choose between consistency and availability.
Cloud-first systems typically choose consistency. When you are offline, you cannot make changes because the system cannot guarantee those changes will be consistent with what others are doing.
Local-first systems choose availability. You can always work, even offline. The system uses CRDTs or similar techniques to ensure that when partitions heal, all changes can be merged without conflicts. The trade-off is eventual consistency: different devices might temporarily see different states, converging over time.
For most personal productivity and finance applications, this trade-off is favorable. Users would rather work now and sync later than be blocked waiting for network access.
The local-first approach is not just theoretical. Several successful products demonstrate its viability:
Linear is a project management tool that has achieved remarkable performance through local-first architecture. Despite being a collaborative tool used by teams, Linear stores data locally and syncs between devices. The result is an application that feels instantaneous. Every action responds immediately because it happens locally first.
Linear uses a custom sync engine to propagate changes. When you create an issue, it exists locally immediately and syncs to the server and other team members’ devices in the background. If you are offline, you keep working. Changes merge automatically when you reconnect.
Figma’s real-time collaboration is powered by CRDTs under the hood. Multiple designers can work on the same file simultaneously because Figma’s data model is designed for concurrent modification. Changes merge automatically without conflicts.
While Figma is primarily cloud-hosted, its underlying technology demonstrates CRDT principles at scale. Their engineering team has published extensively about their multiplayer architecture and the CRDT-like structures they use.
Obsidian is a note-taking application that stores notes as plain Markdown files on your local filesystem. There is no server. Your notes are files on your disk that you can open with any text editor.
For synchronization, Obsidian offers optional services or you can use your own sync solution (Dropbox, iCloud, Git, Syncthing). This approach gives users complete ownership and flexibility. Your notes cannot be locked in a proprietary format, and they survive regardless of what happens to Obsidian as a company.
Excalidraw is an open-source virtual whiteboard that works entirely offline. It stores drawings in your browser’s local storage and can export to files. Live collaboration is available but optional. The core drawing experience requires no server at all.
Apple’s built-in productivity apps use a local-first architecture with iCloud synchronization. Data is stored on device and syncs through Apple’s infrastructure. Critically, the apps work fully offline, with changes propagating when connectivity returns.
The local-first movement is gaining momentum because developers are recognizing concrete benefits:
When data is local, every operation is fast. There is no network latency between the user and their data. This creates applications that feel qualitatively different from cloud-first alternatives.
Users notice the difference immediately. Applications feel “snappy“ or “responsive” in ways that are hard to articulate but immediately apparent. This is not optimization; it is a fundamental architectural advantage.
Cloud-first applications treat offline as an edge case to be tolerated. Local-first applications treat offline as a primary use case. The difference shows in user experience.
With local-first, there is no “offline mode” that limits functionality. There is no anxiety about whether changes will be saved. The application works the same whether you are on a plane, in a basement, or connected to fast WiFi.
When data lives on user devices, users own their data in a meaningful way. They can back it up, export it, inspect it, and take it with them if they switch applications. There is no vendor lock-in through data captivity.
This ownership extends to data longevity. Local data files will remain readable decades from now. SaaS services regularly shut down, leaving users scrambling to export data before it disappears.
Local-first software is private by construction. If data does not leave the device, it cannot be leaked from a server. There is no server to breach, no database to hack, no employee access to abuse.
This is not privacy through policy but privacy through architecture. Users do not need to trust the company’s privacy practices because the architecture makes privacy violations technically impossible.
Running a cloud-first application requires servers, databases, and ongoing operational costs that scale with users. Local-first applications offload computation and storage to user devices. The marginal cost of an additional user approaches zero.
For indie developers and small teams, this changes the economics of software development. You can build sustainable software without venture capital to fund server infrastructure.
Despite the complexity of distributed systems concepts, local-first development can be simpler than cloud-first. You build an application that works on a single device first. Then you add sync on top. The core logic is straightforward application development without the complexity of distributed systems.
Modern sync engines abstract away most distributed systems complexity. Developers work with familiar APIs while the infrastructure handles conflict resolution and state propagation.
Personal finance is an ideal domain for local-first architecture. The requirements align perfectly with local-first strengths:
Financial data is among the most sensitive information people possess. Transaction histories reveal where you shop, what you buy, who you pay, and how much you earn. This data in the wrong hands enables identity theft, stalking, discrimination, and manipulation.
Cloud-hosted finance applications represent attractive targets for attackers. Centralized databases holding millions of users’ financial histories are high-value targets. Breaches are not hypothetical; they happen regularly.
Local-first architecture eliminates this risk category entirely. There is no centralized database to breach because data stays on user devices.
People need access to their financial data in all circumstances: traveling internationally, in areas with poor connectivity, during service outages. A budgeting app that does not work offline is not reliable enough for a primary financial tool.
Local-first finance apps work anywhere, anytime. Your financial data is on your device, accessible regardless of network conditions.
Financial management is inherently personal. Unlike collaborative documents or team projects, most people do not need to share their expense tracking with others in real-time. The single-user optimization of local-first is a feature, not a limitation.
This makes the implementation simpler too. Without real-time collaboration requirements, the sync layer can focus on device-to-device synchronization for the same user rather than multi-user conflict resolution.
People track finances over years or decades. You need your data to be accessible in 2030 and beyond. Will that cloud service still exist? Will they change their pricing? Will they be acquired and shut down?
Local-first data survives independently of any company. Plain data files on your device will be readable for as long as you maintain backups.
For users in certain jurisdictions or professions, storing financial data with third parties raises compliance questions. Local-first architecture simplifies compliance by keeping data under user control.
Budgie is built from the ground up as a local-first personal finance application. Here is how we implement the local-first ideals:
All your financial data, including transactions, accounts, budgets, and categories, is stored in a local SQLite database on your device. We use Drizzle ORM for type-safe database operations, ensuring data integrity while keeping everything local.
There is no Budgie server holding your financial data. We do not have access to your transactions because we never receive them.
Because data is local, every interaction is immediate. Adding a transaction, categorizing expenses, viewing reports: all of these happen at local speed. There are no loading spinners waiting for network responses.
This is particularly noticeable in data-heavy operations like generating reports or searching transaction history. Operations that would require expensive database queries in a cloud architecture complete instantly on device.
Budgie works fully offline. You can track expenses on a flight, review your budget in a remote cabin, or manage finances in areas with no cell coverage. Every feature works without network access.
When you do have connectivity, Budgie can optionally sync with your bank for automatic transaction import. But this is additive, enhancing the local-first core rather than requiring it.
For users who want automatic transaction import, Budgie offers bank synchronization with a zero-knowledge architecture. Your bank credentials are encrypted locally on your device. Sync operations happen directly between your device and your bank. Budgie’s infrastructure never sees your credentials or transaction data.
This gives you the convenience of automatic import without sacrificing the privacy guarantees of local-first architecture.
Budgie’s codebase is open source, allowing security researchers and curious users to verify our claims. You can inspect exactly how data is stored, confirm that nothing is transmitted to our servers, and even build the application yourself.
Open source also addresses the longevity concern. Even if Budgie as a company were to disappear, the code remains available. Communities can maintain and extend it indefinitely.
Your data is yours. Budgie supports exporting your financial data in standard formats. If you ever want to switch to a different application or analyze your data in a spreadsheet, you have full access.
We believe in earning your continued use through quality, not trapping you through data lock-in.
For developers interested in building local-first applications, here are practical starting points:
Several production-ready libraries provide local-first infrastructure:
Yjs is a CRDT implementation focused on collaborative text editing. It powers multiple collaborative editors and has a mature ecosystem.
Automerge is a JSON CRDT implementation that makes it easy to work with complex document structures. It is particularly strong for applications that need to sync arbitrary JSON data.
Replicache provides a sync engine that works with your existing backend. It handles the complexity of offline-first sync while letting you keep your existing server architecture.
PowerSync offers real-time sync for mobile and web applications with Postgres backends.
Electric SQL synchronizes SQLite databases between devices and cloud Postgres, enabling local-first with familiar SQL.
Begin with a single-device application and add sync later. Get your data model right for local storage first. Understand what state your application needs and how it changes.
Then layer sync on top. Modern sync engines make this incremental approach practical. You do not need to design for distributed systems from day one.
Mental models matter. In a local-first application, different devices might temporarily see different states. Design your UI to handle this gracefully.
In practice, for most personal applications, this is rarely visible to users. Sync is fast enough that inconsistency windows are short. But your code should not assume instant consistency.
Think through scenarios like: What if a user makes conflicting changes on two devices before syncing? What if sync fails partway through? What if a device is offline for an extended period?
CRDTs handle these automatically for data merge. But your application logic might need to handle them too. A budget app should behave sensibly if the same transaction is entered on two devices.
The local-first movement is accelerating. Several trends suggest this is not a niche concern but a fundamental shift:
The pendulum is swinging back from maximum centralization toward a more balanced architecture where local and cloud computing each handle what they do best.
The terms are often used interchangeably, but there is a distinction. Offline-first typically means an application that caches data for offline access but still treats the server as authoritative. Local-first goes further: the local device is the source of truth, and the server (if present) is just another peer for synchronization. Local-first implies true data ownership, not just offline caching.
Yes. CRDTs were specifically designed to enable real-time collaboration without central coordination. Applications like Figma and Linear demonstrate that local-first architecture can support sophisticated collaborative features. The key difference is that collaboration happens through peer synchronization rather than through a central server.
Users control their own backup strategy. This might include local device backups (iCloud, Google backup), manual exports, or sync to a service of the user’s choice. Some local-first apps offer optional cloud backup services for convenience, but these are additive rather than required. Your data remains accessible through local backups even if any cloud service disappears.
Initially, there is additional complexity in understanding CRDTs and sync. However, local-first can be cheaper overall because you do not need to build and maintain server infrastructure at scale. For indie developers and small teams, the reduced operational costs can outweigh the initial learning curve. Modern libraries and frameworks also significantly reduce implementation complexity.
Some applications genuinely need server capabilities, like sending emails or processing payments. Local-first is about where data lives and who owns it, not about eliminating servers entirely. A local-first application can use servers for specific capabilities while keeping user data local. The key is that the server handles actions, not storage of personal data.
Local-first apps benefit from a fundamentally better security posture: there is no centralized database of user data to breach. Security concerns shift to device security, which users control through device passwords, biometrics, and encryption. For sensitive data like financial information, this is typically a significant net improvement in security.
The local-first movement represents a genuine evolution in how we think about software architecture. For developers building personal tools, productivity software, or applications in sensitive domains like finance and health, local-first offers a path to better performance, stronger privacy, and genuine user ownership.
Budgie is our contribution to this future: a personal finance application that keeps your financial data where it belongs, on your device under your control.
Ready to experience local-first personal finance? Join our waitlist to be among the first to try Budgie.
2025-02-10
A technical deep-dive into Budgie's offline-first architecture, explaining how SQLite, AES-256 encryption, and device-to-device sync keep your financial data completely private.
Read article→2025-11-06
Discover why offline-first architecture is the only truly private approach for financial apps. Learn about data risks, privacy by design, and how Budgie keeps your finances secure.
Read article→Join the Budgie waitlist and be the first to experience truly private expense tracking.
Join Waitlist