Skip to content
MELLAVIOPEN APP

GUIDE / LOCAL-FIRST

Local-first task management, explained

What it means when your task list begins on your device, where the tradeoffs are, and how Mellavi handles the boundary between local work and optional sync.

LAST REVIEWED /

The local copy changes the starting point

In a cloud-first task manager, the server is usually the authoritative copy. The interface sends changes away and reads them back. A local-first product reverses that priority: the copy on your device is usable on its own, and a server—when one exists—supports rather than defines your access.

Mellavi currently stores your categories, tasks, subtasks, layout, and visual preferences in this browser on this device. You can begin without creating an account, and ordinary task actions do not wait for a network round trip.

Day to day, that means starting is immediate: open the app and work with the queue already on the device. Task content is not uploaded to a Mellavi account because the current local product has no account system, and a lost connection does not interrupt reading or changing an already loaded queue.

The product can also feel responsive because common task operations do not depend on a remote response. Local-first does not guarantee a fast interface, but it removes a network round trip from the ordinary path.

Local-first describes which copy can stand on its own—not a promise that every other data problem has disappeared.

Ownership and recovery are different promises

Browser storage has an important limitation: it belongs to one browser profile on one origin. Clearing site data, using a temporary private session, losing the device, or some storage-pressure scenarios can remove it. Portable JSON backups help you keep a manual copy, but until persistent storage or sync ships, treat Mellavi as a focused working queue—not the only copy of irreplaceable records.

This distinction matters. “Stored locally” describes where the current copy lives; it is not a promise of backup, encryption at rest, permanent retention, or access from every device.

A local-first sync design should preserve a usable local copy and reconcile it across devices. That is harder than simply moving the database to a server: offline edits can conflict, encryption needs careful key handling, and recovery must not weaken privacy.

Mellavi will not describe sync as finished until those guarantees exist in the product. The pricing screen is an interest signal, not a purchase flow.

The useful choice depends on what you need

  • Choose local-first when fast access, offline work, and control of the primary copy matter.
  • Choose an established cloud service when mature collaboration, managed backups, and immediate multi-device access matter more.
  • Ask every product what is local, what is uploaded, how recovery works, and what happens if the service disappears.