Local-first is a default, not a manifesto

"Local-first" has become a loaded phrase in the last few years. It carries a lot of cultural weight — privacy advocacy, surveillance critique, distrust of large platforms. There are conferences. There are essays. There is a flag people wave.

Avery NXR is local-first. We are not waving the flag.

We chose local-first because, for the specific job of scaffolding a Next.js application, it is the better default. Not the better ideology. The better default — the choice that produces a better tool for the user, all else equal.

What local-first means in our context

Inside Avery NXR, "local-first" means three concrete things.

First, the model runs on the user's machine. The Small Language Model that generates code is shipped inside the desktop app. No API key, no usage meter, no network hop to a frontier provider.

Second, the user's project lives on the user's machine. Prompts, generated code, audit ledger, plugin manifests — all of it is files on the user's disk. We can sync to a backend if the user wants it. We will never require the backend to use the product.

Third, every action the user takes works offline. Generate code, scaffold a new app, install a plugin (after first download), review the audit ledger — none of it depends on being connected.

Those are the rules. They are not philosophical commitments. They are product decisions about where data should live and what should keep working when the wifi drops.

Why this is the better default

For some categories of software, local-first is a worse choice. Collaborative editors are worse local-first — that is what cloud sync is for. Search across the entire web is worse local-first — that requires an index nobody can fit on a laptop. Real-time multiplayer games are worse local-first — the server is the source of truth.

Scaffolding code is not in any of those categories. Scaffolding code has the opposite shape.

It is a single-user operation. You are not collaborating on the prompt; you are writing the prompt yourself.

It is a bounded operation. The model does not need access to the internet to know how next-auth works. The knowledge is in the model weights.

It is a high-confidentiality operation. The prompt is, by definition, a description of something you have not built yet. It is the most sensitive thing on the machine.

It is a latency-sensitive operation. As covered elsewhere, the iteration loop dominates the experience.

For a single-user, bounded, confidential, latency-sensitive operation, local-first is not a stylistic choice. It is the choice that matches the shape of the work.

Where we are explicitly not local-first

The audit ledger is local by default but can be synced to a team repository — that is what teams want. The plugin registry is online — there is no version of plugin distribution that works without a network. Software updates pull from our update server. Telemetry, if the user opts in, is sent to us. There are parts of the product that work better with the network. We use the network there.

The principle is not "the network is bad." The principle is "default to local where the shape of the work supports it." On the parts where the network is genuinely better, the network wins.

This is a less satisfying position than the maximalist one. We are not against the cloud. We are not for the cloud. We are for whichever default produces a better tool for the specific operation.

The thing the manifesto framing gets wrong

The pure local-first manifesto holds that user sovereignty over data is the goal, and any concession to the network is a compromise.

The problem with that framing is that it places ideology above ergonomics. A purely local-first tool, as a matter of principle, will sometimes be worse than a tool that picks its battles. The user does not benefit from a product that is purely local-first if the purity costs them functionality they would have preferred.

Conversely, the cloud-by-default manifesto holds that scale, convenience, and collaboration always trump local execution. The problem there is the opposite: scale becomes a justification for designs that put data, work, and identity in places the user did not choose.

Default to local where it is better. Default to network where it is better. Let the user feel like the choice was made on their behalf, not on principle.

What this means for users

Practically, it means the following.

You can use Avery NXR without an internet connection, after the initial install. The model is local. The generators are local. Your project never leaves the machine. None of that requires a setting to enable. It is just how the tool works.

You can also sync your audit ledger to a Git repository. You can install plugins from the online registry. You can opt into team features that require the cloud. None of that compromises the local-first defaults. The defaults stay; the optional online features layer on top.

If you have a manifesto, the tool will not get in your way. If you don't have a manifesto, the tool will still work the way you expect, because the defaults are sensible.

That is what local-first means here. A sensible default for a specific kind of work. Not a flag.