Why Flowo Is Local-First Without Multi-Device Sync

What Flowo has and what it does not

Flowo does not synchronise data between devices. The codebase contains no CRDT library and no merge logic, and the backend has no table that holds a person's tasks. We are stating this plainly because the earlier version of this article described conflict resolution in general terms, and that could be read as a description of our product.

There is also no account. The app has no sign-in screen and asks for no email address or password. Each install has a random identifier that is scoped to the app and used to authenticate requests to our backend.

Where the data lives

Everything a person creates in Flowo is written to Hive boxes on the device, encrypted with AES-256. The key is generated on first launch and held in the iOS Keychain or the Android Keystore. On iOS it is excluded from iCloud Keychain sync.

The work that depends on that data also runs on the device. The planning engine is deterministic Dart code that builds the schedule locally. Text embeddings used for classification come from models bundled with the app and run through Core ML on iOS and TensorFlow Lite on Android. Reminders are local notifications reconciled from the schedule after each change.

The app therefore plans and sends reminders with no network connection. Features that call a language model need one.

What leaves the device

Content leaves the phone only for a specific request, and each kind of request has its own rule.

• Cloud AI: breaking a task into steps or estimating its length sends that task's title, and notes where the feature uses them, to our backend, which calls the model. Notification wording is requested the same way from the titles of upcoming items.
• Voice: dictation is gated by a separate voice upload consent asked at the first recording. The app receives a signed address valid for 60 seconds and streams microphone audio directly to the speech service, so the audio does not pass through our backend.
• Analytics: off until consent is granted. Events carry no titles or notes, and task identifiers are hashed.
• Purchases: handled by the app stores through a payment SDK.

The backend state we keep per install is a device record and daily usage counters. It also issues short-lived tokens that group the model calls of one assistant message. The access token itself lasts about 15 minutes and is held in memory on the phone. The delete flow asks the backend to scrub the device record and then erases local data. A network failure does not block the local erasure.

Why we chose not to build sync

Sync requires things the product does not have. It needs to know that two devices belong to the same person, which means an account or a pairing step. It also needs a server that stores plan content, and our backend has no table for tasks or schedules.

The encryption design points the same way. The storage key never leaves the device, so a second phone could not read a copy of the first phone's boxes. Sync would need a way to share a key between devices that we can explain and defend. We have not designed one.

The data model is the third reason. A Flowo schedule is derived: the engine computes it from tasks, habits, settings and the clock. Two devices that each replan offline produce two valid schedules, and merging them block by block would produce a third that neither engine run approved.

What the choice costs

The cost of this design is that a plan exists in one place. A person with a phone and a tablet cannot see the same schedule on both.

Moving to a new phone is the harder case. On Android we disable the platform's app backup in the manifest, so the plan is not carried in a Google backup. The app can export all data as a JSON file through the system share sheet, and it has no import. An export is a copy for the person's records and cannot be loaded into another install. We accept these costs for now.

What sync would need first

Before adding sync we would need to settle five things, and only one of them is the merge algorithm.

1. 1.Identity. A way to link devices that fits an app with no account today.
2. 2.Keys. A way for a second device to obtain the storage key without our server being able to read the data.
3. 3.Change metadata. Our task records store a creation time and no modification time or version, so two edits to the same task cannot currently be ordered. Braindump items do carry an updated timestamp.
4. 4.Merge rules per data type. The consent ledger is already an append-only log, which merges by union. Individual settings are single values, where a last-writer-wins register is acceptable. The set of tasks needs add and remove semantics that survive concurrent deletes, which is where a CRDT set would be used.
5. 5.Derived data. Scheduled blocks are stored inside the task record today. We would sync the inputs and let each device rebuild its own schedule and notifications.

Version skew is a further problem that our own migration code makes visible. Each install records its migrations locally, and a build skips stored types it does not recognise by reading them as null. A record written by a newer build and synced to an older one could be read as missing. Sync would need a schema version on every record and a rule for what an older build does with a newer one.