The default shape of a modern application is a thin client chatting to a server somewhere else. The data lives in a data centre; your device is just a window onto it, fogging up whenever the wifi dips. This is so standard that most people never notice it was a choice at all. In medicine it is often the wrong one.
Local-first is the alternative: the data lives on the device that created it, the application works fully offline, and any sync is a bonus rather than a precondition for the thing functioning. The phrase comes from a 2019 essay by a research group at Ink & Switch, but the idea is older than the cloud — it is simply how software worked before we collectively decided that everything, including a spreadsheet, ought to phone home.
Where does your data sleep?
Before the table, a demonstration. Flip the switch and watch what happens to a single record when you press save. One architecture sends it on a long round trip to a building you will never visit, past at least one stranger who could in principle read it. The other keeps it exactly where it was born. The difference is not philosophical — it is latency, privacy, and what happens the moment the network sulks.
Five rows that decide it
The trade-off is not abstract, and it is not a matter of taste. Lay the two architectures side by side against the things that actually matter for a clinical tool and one of them quietly stops looking like the obvious default.
| Cloud-first | Local-first | |
|---|---|---|
| Information governance | Identifiable data leaves the device; you owe an honest account of where it lives and who can reach it | Data never leaves the device unless you choose to move it; the IG conversation is mercifully short |
| Latency | Every action is a round trip; slow or flaky networks quietly become your problem | Reads and writes are instant; the network is never in the critical path |
| Cost | Scales with users and storage, forever, like a subscription you forgot to cancel | A file on a disk; effectively free to run |
| Data ownership | You hold an account, not the data; export is a feature someone graciously grants you | You hold the file; the application is replaceable, the data is yours |
| Offline use | Degrades to a spinner | Unaffected — offline is simply the normal case |
The governance row is the one that should make a clinician sit up. The moment identifiable information sits on a server, you owe an honest answer to where it lives, who can reach it, and what happens when the company is acquired, pivots to selling dog food, or simply folds. With a local SQLite file on a machine you control, that entire genre of question mostly evaporates. You are not staking a patient’s confidentiality on a vendor’s security posture and a sufficiently long privacy policy; you are responsible for one file.
The cloud is just someone else’s computer — which is fine for some things, and a genuinely odd place to leave a patient’s data by default.
There are real costs, and pretending otherwise would be its own kind of marketing. Sync across devices is genuinely hard — anyone who tells you it is easy is selling you a sync service. You give up the casual luxury of opening your work on any browser anywhere. Backups become your job rather than an assumed background process you never think about. But for the kind of tool a clinician actually builds for themselves — a logbook, an audit tracker, a prep tool — none of those costs really bite. The data is yours, it is small, and it has no business being anywhere but in your hands.
It is also just faster
Set governance aside entirely and local-first still wins on the thing you feel a hundred times a day: speed. There is no spinner, no hopeful little progress bar, no waiting on a server when the data is already on the disk in front of you. Software that responds instantly changes how you use it — you stop unconsciously batching your work around the lag and start treating the tool as an extension of your hands rather than a colleague who is always slightly distracted.
This is the same argument as building your own tools in the first place: the person who feels the friction should be the one shaping the fix, and they should not have to rent a data centre to do it. I have written separately about why surgeons should build their own software. Local-first is the architecture that makes that practical and safe — a whole system in one folder, one file per project, nothing phoning home while you sleep.
The reflex to reach for the cloud is mostly habit wearing the costume of good engineering. For a great deal of clinical software, the honest default is the exact opposite: keep the data on the device, make the network optional, and own the file. The boring choice is, with tedious reliability, the correct one.