Somewhere around 2015 the industry quietly redefined the word “app” to mean “a thin shell around somebody else’s server,” and the redefinition stuck so thoroughly that a piece of software which opens its own files without asking permission from a data center now feels almost eccentric. We did not set out to be eccentric; we set out to build tools that keep working when the Wi-Fi drops, when the vendor sunsets the product, when the account gets locked by an automated fraud system at 2 AM, and the shortest path to all three of those guarantees turned out to be the same one: make the app complete on the machine it runs on, and treat the network as an optional extra rather than a load-bearing wall.
That is the whole thesis, and everything else in this post is what it looks like when you actually live by it across a dozen projects instead of printing it on a landing page.
What the constraint looks like in practice
Tailshell gives you a persistent web terminal and it runs behind your own Tailscale or reverse proxy, because a terminal that phones home is a terminal somebody else can read. Sinema plays your media library on Android TV against a Stash server on your own hardware, with no streaming service in the middle and no “this title isn’t available in your region,” because the region is your living room. Roamarr keeps your itineraries, passport scans, and expenses in one Docker container you control, because the one dataset you really do not want in a breach notification email is the one that says where you sleep and when you are not home. Foxden manages your Firefox workspaces in localStorage and syncs through Firefox’s own account machinery if you want it to, SpiderTypes teaches kids to type with no backend at all, and Kanoprii edits PDFs in a single 30 MB binary that has never heard of a license server.
The Grexa, LinSight, and LinSync family takes the same shape on the systems side: the daemon samples sensors on the box it runs on, the clients talk to it over a Unix socket or an mTLS tunnel you issued yourself, and the day our website disappears forever, every installed copy keeps doing exactly what it did the day before, which is the actual test of whether you own your tools or rent them.
What offline buys you that the cloud cannot
The obvious win is privacy, and it is real, but it is also the least interesting one, because the deeper wins are operational. An app with no account system has no credential database to breach, no password-reset flow to maintain, no session tokens to rotate, and no compliance questionnaire asking how you store PII, because whatever PII exists lives on the user’s hardware and never touches a server of ours, and the entire category of incident that starts with “an attacker gained access to our user database” simply does not exist for you. An app with no telemetry has no analytics pipeline to break, no consent banner, and no awkward moment where a user reads the network traffic and finds out what you really collect, because what you really collect is nothing and the firewall log can prove it.
The second win is latency and determinism, and it is the one engineers feel first. When the data is on the same machine as the code, the p99 is the disk, not the disk plus a TLS handshake plus a queue plus somebody else’s incident, and when the app misbehaves you can strace it, tcpdump it, and read the files it wrote, because the whole system is sitting right there in front of you instead of being a black box with a status page. I spent years debugging PHP apps where the database was one mysql_connect away on localhost, and while I do not miss magic_quotes, I do miss the property that the entire failure domain fit on one screen, and local-first is how you get that property back without giving up the last twenty years of tooling.
The third win is longevity, and it is the one nobody prices in until it matters. Software that needs a vendor’s server dies on the vendor’s schedule, and the history of the last decade is a long list of products people loved that became inert installers the day the business model moved on, whereas a self-contained app with a documented file format survives the vendor, because the binary still runs in a VM or an emulator and the data outlives the binary entirely, readable by whatever tooling comes next, since the format is the part that was never a black box.
The honest tradeoffs
Local-first is not free, and pretending otherwise is how these essays turn into marketing. Sync between machines is genuinely hard, and the moment a user wants the same data on a laptop and a phone you are either building conflict resolution or shipping a server, and we chose to ship small servers the user owns rather than pretend the problem away, which is why Roamarr is a container you run yourself instead of an account on our infrastructure. Updates are harder too, because there is no single deployment to fix, so a bad release lives on user machines until they upgrade, and that forces a discipline around changelogs and backwards-compatible file formats that hosted software gets to skip. And collaboration, real simultaneous multi-user editing, is still easier with a central authority, which is why none of our apps pretend to be Google Docs.
There is also a discovery cost that nobody warns you about: when your app makes no network calls, users quite reasonably ask whether it is abandoned, because the industry has trained people to expect a login screen and a spinning sync icon as proof of life, and an app that quietly does its job looks dead by comparison, which is a strange expectation to have to design around.
The cloud as one option among many
None of this is an argument that the network is bad; it is an argument about defaults. Tailshell is more useful with Tailscale, Roamarr can share a trip with a companion, LinSight’s whole point is watching more than one machine, and all of those are network features layered on top of an app that already works with the cable unplugged, which is the difference between a feature and a dependency. In 2005 we built apps that worked offline because the network was slow and expensive, then we spent fifteen years building apps that broke offline because the network was fast and cheap, and in 2026 the network is fast, cheap, and hostile enough that the old default is worth revisiting on its merits rather than on nostalgia.
The modern equivalent of “the app runs on your machine” is not a throwback, it is a sizing decision: keep the failure domain small, keep the data where the user can back it up with cp -r, and add connectivity where it earns its keep. That is the whole pattern, and a dozen shipped apps later, the surprising part is not that it works, it is that it was ever considered weird.