When we build a tool for ourselves, the starting assumption is that it runs on the machine in front of you, not on a server somewhere. The cloud is the thing we add when a job demands it, not the default we reach for first.
The choice depends on the work the tool needs to do. Local storage gives us a useful starting point, but sharing, backups and connected features still need deliberate decisions.
Local-first has a fairly precise meaning. The main copy of the data lives on your own device. Work on local files can continue without a network connection where the app supports it. Sync, shared services and connected AI may still need an internet connection and an account. Local storage describes where data is kept; it does not mean every feature runs offline or that data never leaves the device. The idea has a proper lineage in software research, but the version that matters to us is the everyday one: the tool keeps a useful copy of your work close at hand.
Local-first keeps data on the machine
We build Mac apps for our own studio and start with local storage where the job allows it, for the same handful of reasons.
Local storage reduces what needs to be uploaded. A lot of what our tools touch is the kind of thing that should not leave the building at all: source code, copies of development databases, half-finished drafts, client material under embargo, our own notes about live projects. Keeping a working copy on the machine gives us more control over it. We still need to check what each connected feature sends elsewhere, and protect the device and its backups. Storage alone does not settle whether a tool is suitable for sensitive material.
Local operations can avoid the wait for a server response. Opening files and working with saved data can feel quicker, while AI requests and other connected features still depend on the service and connection. A responsive tool changes how often you reach for it. The friction of a login screen and a half-second delay is enough to stop people using a tool thirty times a day, which is exactly the frequency at which a small tool earns its place.
There can be less hosting to manage. A standalone local feature does not need a hosted service to do its job. Shared features and external AI still bring service dependencies and possible running costs. The app itself needs maintenance too: operating-system changes, security fixes and backups all need attention. For internal tools that exist to save time, reducing those costs is useful, but local storage does not remove them.
A standalone local tool can avoid another account for the team. Installing it may be enough for its local features. Connected services can still require a login, credentials or a subscription, so we check those requirements alongside the installation. That keeps the practical cost of using the tool clear.
Clio makes the trade-off concrete
The example that makes this real is one of our least visible tools. Clio is our shared AI memory. It gives connected AI assistants a shared store to read from and write to, so notes, decisions and project context can carry across the tools we use.
Clio can store those notes in a local database, but the storage location is only part of the picture. Its search can process text locally or send it to an external AI service, depending on the configuration. Connected AI assistants can also read the notes they are given access to. We therefore need to check both the search settings and the assistants using that memory before deciding what information belongs in it.