Engineering
What we gave up by not shipping a web app
Native and local-first are choices with a bill attached. Here is what is actually on it.
5 min read
It is easy to write a marketing page about local-first software and never mention that the approach costs something. It does. Both NabuSuite apps are Tauri 2 desktop applications with Rust underneath, and that decision has consequences we live with daily.
The bill
- Platform work does not generalise. NabuVoice's macOS build ships; its Windows build is scaffolded and has never been compiled or run on a real Windows machine. On the web that sentence would not exist.
- Shipping is slower. There is no deploy button — there are signed builds, per-platform installers, and update mechanics for three operating systems.
- We cannot see anything. No server-side analytics on a local-first app means bug reports are what you tell us, and nothing else.
- Every model is a download. Speech and correction models are hundreds of megabytes that arrive on your disk instead of running on someone else's.
What we got
In exchange: dictation with no per-minute meter, because your machine did the inference. Agent sessions that survive the app closing, because a daemon on your machine owns them. Work that stays yours when a subscription lapses, because it was never in our custody. An app that keeps working on a plane.
The performance argument matters too, and it is a stated product value rather than an accident. Unused features are meant to consume zero resources — live terminal renderers are pooled and capped, and a pane that is not visible does not get to cost you anything.
The honest summary
Local-first is not free, not obviously correct, and not the right answer for every product. For a dictation tool that hears everything you say, and for a workspace that runs agents against your source code, it is the answer we are willing to pay for.
The test is simple: if our servers went away tomorrow, would your software still work? It should. That is the whole idea.