It is easy to list “runs locally” alongside a dozen other bullet points, as though it were one feature among many — somewhere between the export options and the dark mode. We think it belongs in a different category. Where a tool does its work decides what it is able to promise you, and local-first is the difference between a promise you have to trust and one you can check.

That distinction is the whole argument. A great deal of software asks you to believe that your data is handled carefully somewhere you cannot see. Local-first asks you to believe far less, because there is far less to believe in. When the work happens where you are, the guarantees stop being assurances about a distant system’s behaviour and start being facts about your own.

A promise you can check

When the work happens on your own machine, privacy stops being a policy and becomes a property. There is no copy of your data sitting on a server to be protected, leaked, subpoenaed, or repurposed — because there is no copy at all. There is no account quietly linking your activity to your name, and no telemetry measuring what you do in the background. You are not asked to believe that the data is handled carefully somewhere out of sight; the data simply never goes out of sight.

This is why we resist treating “local” as a feature. A feature is something a vendor can give you and, just as easily, take back in the next release. A promise of this kind is structural: it follows from where the computation happens, and you can confirm it the same way you would confirm anything physical — by noting that nothing left. The verification is not a matter of reading our policy and trusting our word. It is a matter of where the data is, which is somewhere you control.

Residency as the customer’s choice

Local-first does not mean a single rigid arrangement. In clinical settings the honest position is that the right place for data depends on the institution, and the institution — not the vendor — should decide. So the principle we hold to is that data residency is the customer’s choice.

Across our clinical platform, the edge tools and pods are deployable on-premises or in a hybrid arrangement, and that choice scales from a small clinic to a large hospital. A practice that wants everything to stay inside its own walls can run on-premises, with the information system and the archive sitting on equipment it owns and controls. An organisation that has reasons to keep some functions central and others local can choose a hybrid arrangement and draw the line where its own governance, not ours, says it should be. The platform’s job is to make either choice fully workable rather than to push everyone toward the one that is most convenient to operate.

The pods make this concrete. EndoPod, PathoPod and TomoPod each bring the information system and the archive to where the care happens — endoscopy, pathology, radiology — and they do it within the standards the rest of medicine already uses: DICOM and HL7, with HIPAA-aligned handling throughout. Choosing on-premises or hybrid does not mean stepping outside the ecosystem; it means deciding where your data lives without giving up interoperability with everything else.

Why hybrid still keeps the promise

It would be simpler to claim that only fully on-premises deployment counts, and that anything touching the cloud has broken the promise. That is too blunt to be true, and pretending otherwise would not serve the institutions that have legitimate reasons to use both.

The reason hybrid can still keep the promise is that the exchange between the edge and anything central is asynchronous and deliberate, rather than a live dependency that has to be reached before work can be done. The tools at the point of care do their work where the care is; information moves between the edge and the wider system on its own schedule. That design choice has two consequences that matter here. The first is resilience: care does not stall because a remote connection is slow or down, since the local system is not waiting on a round trip to function. The second is control: because the movement of data is something the institution configures rather than something that happens implicitly with every action, the boundary stays where the customer drew it.

Hybrid, done this way, is not a hole in the promise. It is the promise honoured under a different set of constraints — the institution still decides what stays local and what does not, and the system still works when the link to the wider world is imperfect.

Trust, resilience, and the balance of power over time

Local-first also changes the balance of power over time. A service somewhere can change its rules, raise its price, or shut down, and there is little you can do about it. A tool that runs where you are keeps working on your terms: no connection to drop at the wrong moment, nothing that stops being yours because a company decided to move on. That independence is quiet, but it is the whole point.

In a clinical environment the stakes of that independence are higher than inconvenience. A workflow that depends on a remote service is a workflow that can be interrupted by something entirely outside the clinic’s control. Keeping the work local — and keeping data residency in the institution’s hands — means the people responsible for care are also the people who control the conditions under which that care happens. Trust, in this framing, is not a feeling about a vendor. It is a consequence of where things run and who decides.

The trade we make on purpose

None of this makes local-first the easy choice to build. It is harder, and it forecloses some convenient shortcuts. We accept that trade deliberately, because the alternative asks the people who use our tools to trust more than they should have to. A promise you can verify is worth more than one you are merely asked to take on faith.

That is what we mean when we say local-first is a promise rather than a feature. A feature is something we add. A promise is something we owe, and the way we keep it is by building so that where your data lives is your decision and not ours — so that the most important assurance we make is one you never have to take on trust, because you can simply see that it is true.