“Local-first” is easy to turn into a slogan. It is harder to define when the product uses remote model providers for some of its most demanding work. For WolfeWriter, the phrase does not mean that every inference step must happen on the Mac. It means the manuscript and the project remain useful, durable, and recoverable in the writer’s local workspace without depending on a cloud document service.
That starts with ownership. The book should open when the network is unavailable. Chapters, planning data, Story Memory, annotations, snapshots, and indexes should belong to the local project rather than to a remote account that the editor quietly depends on. A provider may be unavailable, but that should prevent a provider operation, not prevent the writer from reading or editing the manuscript.
Credentials need an even sharper boundary. An API key is not ordinary project configuration and should not sit in a JSON file beside a chapter. Provider settings such as a base URL and model name can be stored with the local application state, while the secret belongs in macOS Keychain. The point is not to make setup mysterious. It is to keep a manuscript backup from becoming an accidental secret backup.
The Mac platform helps when the application respects it. Native windows, menus, text input, undo, selections, and accessibility are not decoration around a web application. They are part of how writers use the machine. A long-form editor needs the operating system’s text behavior, especially for IME composition and bidirectional writing. Replacing native behavior with a custom shortcut or a browser-like text surface can make the app look consistent while making it feel wrong.
Local-first also changes how background work should behave. A writing app may want to extract candidates, refresh annotations, or prepare continuity observations after a chapter changes. Those jobs should be explicit about what they read and where their results go. A stale result should not be projected into a newer manuscript. A missing local resource should produce a visible typed error instead of an empty panel that looks like a successful analysis with nothing to say.
Remote inference remains useful. Long drafting, deep critique, and major rewrites may need a provider that is not available on-device. The writer should be able to configure one, understand that it is being used, and review the result before it changes the book. Local ownership is not a claim that the Mac can do every computation. It is a refusal to make remote inference the owner of the project.
This boundary is particularly important for fiction because a manuscript is not interchangeable with a normal cloud document. It contains unfinished decisions, private material, and context that may not make sense outside the book. Sending every chapter to an API for routine extraction is a poor default when much of the work can be deterministic or local. The application should earn the right to ask for remote help by making the scope and the reason clear.
Building on macOS has made these decisions concrete. There is no universal abstraction that removes the need to understand text input, file ownership, StoreKit, Keychain, or window behavior. That is more work at the beginning, but it also means the product can make fewer promises it cannot keep. A local-first writing app should feel ordinary in the important ways: the document is there, the undo stack works, the project can be recovered, and the writer remains in control of where the book goes.
It also means being honest about what local ownership does not solve. A file on the Mac can still be lost without backups. A local model can still produce a bad suggestion. A Keychain credential can still be unavailable after a system change. Local-first is not a magical privacy label or a guarantee of perfect software. It is a set of responsibilities: keep the project usable without a service, make remote work explicit, preserve recovery paths, and avoid turning the writer’s data into an invisible dependency of the product.
That responsibility is worth the extra care because it makes failure easier to understand. When a provider is down, the manuscript remains available. When an extraction resource is missing, the application can say so. When a writer removes a provider, the project does not disappear with it. The boundaries are useful precisely because they let one part of the system fail without taking the book with it.
For a small product, this can feel like an inconvenient amount of engineering. There is always a faster demo if the manuscript is held in memory, the provider configuration is global, and the background job is allowed to write wherever it likes. Those shortcuts are difficult to unwind once real books depend on them. Starting with ownership and failure boundaries is slower in the first week, but it gives later features somewhere safe to live.
That is the difference between a local-first product and a product that merely happens to have a local mode. The former makes ownership visible in its storage, failures, settings, and recovery behavior. Those are not glamorous details, but they are the details a writer encounters when the network disappears or a project needs to be moved.
WolfeWriter is built around that definition. The model may be local, remote, or absent depending on the task and the writer’s settings. The project remains local either way, and that distinction should remain understandable even to someone who never opens the settings screen.
