Why we build local-first apps
by zwaystudios2 min read
Look across the Zway Studios apps and a pattern shows up. ZwayRecord writes your screen recordings to your own disk. ZwayVoice transcribes speech on your phone. LocalDub dubs video on your Mac. ZwayDesign keeps your documents in your browser. That is a deliberate choice, and this post explains it.
What local-first means
A local-first app does its real work on the device in front of you. Your files live there first. The network is optional: used for updates, backups you switch on, or a feature that genuinely needs a server, and never as a requirement for the basics.
Why it is better for you
It is faster. There is no upload before the work starts and no queue on someone else’s server. A transcript appears while you speak. A recording is saved the moment you press Stop.
It works offline. On a plane, on a patchy connection, or when a service is down, a local-first app still does its job.
It is private by design. The easiest way to keep your data safe is to never send it anywhere. A voice note that never leaves your phone cannot leak from a server.
You are not renting your own files. No account is needed to open what you made, and the app cannot hold your work hostage.
Where we still use the cloud
Local-first is a default, not a religion. Some jobs need a server:
- ZwayRank has to ask ChatGPT, Gemini and Claude questions and publish to your website, so it is a web app. Even there, it runs on your own model keys, with a spend cap you set.
- Some apps offer an optional cloud feature, such as ElevenLabs voices in LocalDub or Google Drive backup in ZwayVoice. They are off until you turn them on, and they use your own account.
Every app page has a Privacy section that says in plain words what stays on your device and what, if anything, leaves it.
The trade-offs
Local-first has costs, and we would rather say so. Heavy models need a capable device. Files in browser storage disappear if you clear site data, so you should export what matters. Sync between devices is harder. We think those trade-offs are worth it for the apps we build, and we design around them where we can.