Local-first before I knew the phrase

Before I had a phrase for it, I kept preferring tools that did their work on the device in front of me. The reason was practical. If the input is personal, an upload creates another system to trust, secure, explain, and eventually clean up. If the work can happen locally, that entire layer may be unnecessary.

Local-first does not automatically make a project private or good. A browser can still store too much. A desktop app can still expose information in logs, screenshots, or exports. The interface still has to explain what it reads, where it keeps the result, and which action leaves the device. The useful part of the approach is that it creates a strong default: keep the data near the person unless a remote service is essential to the job.

That default changes product decisions. Importing an export can be better than asking for account credentials. An on-device frame can be enough for guidance without sending an image to a server. A local audit trail can describe what a Windows tool requested without turning every event into telemetry. These choices may limit convenience or require more careful state handling, but the limits are visible and understandable.

I also like how local-first tools fail. A network outage should not erase the main workspace. A discontinued service should not make someone’s own data unreadable. There are still updates, backups, and compatibility problems to solve, but the center of gravity stays with the user. I did not begin with a manifesto. I began with discomfort about unnecessary uploads. The phrase came later; the instinct was simply to make the smallest trust request the tool could honestly make.