Local-first is a product decision

“Local-first” sounds architectural, but users experience it as a promise: their work remains available, their data stays close, and the product does not become useless when a service disappears.

Start with the failure mode

Architecture discussions often begin with storage or synchronization. A clearer starting point is failure. What happens with no network? What happens when a provider rejects a request? What remains when the user removes an account?

Those answers define whether local operation is a real product mode or a cached imitation of the hosted one.

Make ownership visible

Keeping data local is not enough if export is obscure or credentials are silently forwarded. Ownership needs visible controls: where a model runs, which provider receives a prompt, where an artifact is saved, and how to move it elsewhere.

type ExecutionTarget =
  | { kind: "local"; modelPath: string }
  | { kind: "provider"; provider: string; model: string };

Explicit state may add one decision to setup. It removes much larger uncertainty later.

Native surfaces raise the bar

Desktop software inherits platform expectations around permissions, shortcuts, files, and background work. A local model can be technically impressive and still feel unreliable if those edges are vague. The mundane platform details are part of the AI experience.