Local-first is a product boundary, not a storage checkbox

“Data is stored locally” is useful, but it is not a complete product promise. A local-first desktop product also needs to explain who owns the authoritative state, what remains usable offline, how recovery works, and when information is sent elsewhere.

Four questions I use

Where is the source of truth?

For Store Payroll Assistant, the desktop workspace owns operational state. The interface cannot depend on a hosted account to open a month, review employee input, or restore a backup. That makes the local file format and validation boundary part of the product architecture.

What happens when something goes wrong?

Local data without recovery is only locally fragile. Manual backups, automatic recovery points, import validation, and clear restore behavior matter as much as the primary save path. Recovery should be an operator workflow, not a hidden implementation detail.

What leaves the machine?

Aura keeps preferences and history on the device, but translation text is sent to the provider the user selects. Calling the whole experience “private” without stating that boundary would be misleading. The useful promise is precise: no hosted backend owned by Aura, direct provider requests, system credential storage where supported, and optional screening before automatic clipboard translation.

Can the user understand the boundary?

Architecture alone is not enough. Product copy should distinguish local history from remote inference, automatic recovery points from deliberate off-device backups, and a local PIN from encryption. A truthful limitation builds more trust than an expansive privacy label.

A practical definition

For the products I am building, local-first means the essential workflow and authoritative working state live on the user’s device; network features are explicit; and the product provides a comprehensible path to inspect, back up, and recover that state.

That definition is narrower than a manifesto. It is also testable.