Local-first software: what it changes in practice
“Local-first” can sound like a privacy label. In practice it changes architecture, costs, failure modes and the expectations a product places on the device running it.
Start with the job, not the architecture
The useful question is not whether every feature can be local. It is whether keeping a particular part of a workflow on the device improves the product. A small database, document archive or deterministic calculation can be a natural fit. A very large generative model may be a poor fit on a device without enough memory. Treating both cases the same would turn a principle into a restriction.
Local processing changes the failure model
A cloud-dependent feature can stop working because a service is unavailable, an account cannot authenticate or a network connection disappears. A local feature avoids some of those dependencies, but gains others: device storage can fill up, operating-system versions differ and hardware performance varies. Good local-first software therefore needs explicit handling for backups, migrations, resource limits and recovery.
Cost and privacy sometimes point in the same direction
When useful work happens on the user's device, less user data needs to leave it and the developer may avoid paying for a remote operation every time the feature is used. Those are meaningful advantages for a small independent studio. They are not free advantages: development and testing become more important because the software must behave across hardware the studio does not control.
Why Nyfir Studios uses the idea selectively
FigureDesk is designed around locally stored business information and workflows. DroidBake explores local toolchains and local AI where practical. EIRVID explores on-device creative processing as a direction. These products have different requirements, so “local-first” cannot mean an identical technical recipe for all three.
A useful rule
Keep a capability local when doing so gives the user more control without making the workflow meaningfully worse. Use a remote dependency when it solves a problem the device cannot solve well enough. Most importantly, make that boundary understandable rather than hiding it behind a slogan.