How the Project Started
The idea for Synccraft emerged from a recurring pattern across my personal applications. I’m building several tools that need to work offline and sync across devices: a home inventory, an expense ledger, a knowledge management system, and a medication tracker. Each of these apps needs data consistency, but none of them requires a traditional backend architecture.
The Core Insight
The apps I’m building are fundamentally different from typical SaaS applications. They’re personal tools that need to work reliably without an internet connection. The data lives on the device first. Cloud sync is optional—a convenience, not a requirement.
This led to a fundamental architectural decision: the library is an access layer for data, not a backend service. Clients work standalone. When you want to sync, you choose a backend. The sync mechanism is pluggable.
Why Not Just Use Existing Solutions?
There are excellent CRDT libraries out there, but they typically focus on the data structure level. What I needed was a complete sync architecture: local storage, encrypted documents, multiple sync backends, and a clean API that apps can build on. The relationship between documents (foreign keys, cascading deletes) should be handled by the application layer, not the sync engine.
The decision to build a sync library rather than using existing CRDT implementations reflects a deeper understanding of the problem domain. Most sync solutions assume a client-server architecture. Synccraft’s local-first approach with pluggable backends is a fundamentally different paradigm—one that prioritizes user autonomy and data sovereignty.