Why privacy-first architecture wins

For a decade, software architecture optimised for scale, speed and acquisition. Privacy arrived later, usually in response to a regulator or a bad week in the press. That order of operations is expensive, and it shows in the results.

The cost of retrofitting

Adding privacy controls to a finished system produces contradictions. Data minimisation policies that fight the analytics pipeline. Encryption layers that break search. Consent flows bolted onto collection that was never questioned. The architecture was not designed for any of it, so every new feature pays a tax.

The pattern repeats. Companies collect by default, store indefinitely, then discover that deletion requests are an engineering project. They train models on user data and then cannot answer basic questions about provenance. Hoarded data compounds like debt.

Inverting the default

A privacy-first architecture asks a different opening question. Not "what can we collect?" but "what is the least we need to make this work?" Not "where do we centralise this?" but "can this stay on the user's machine?"

The engineering benefits are concrete:

• Reduced liability. Data you never hold cannot be breached, subpoenaed or misused.
• Simpler compliance. Obligations that are architectural become checklists rather than rebuilds.
• Better latency for sensitive work. Local processing has no round trip.
• Trust you can demonstrate. A claim that can be checked is worth more than one that must be believed.

What the constraint did to Velum

When we started Velum we set a rule that sounded like a handicap: no accounts, no cloud processing of your content, nothing sent off the device at runtime.

It forced better engineering. We could not lean on a server-side model, so we had to make on-device detection genuinely good, which meant quantised models small enough to bundle and a pattern layer strong enough to stand alone. We could not personalise from behavioural data, so the interface had to work without knowing anything about you. We could not fall back on a support team reading your documents, so error states had to explain themselves.

The result is a tool that works offline, starts instantly, and has a much smaller surface for anything to go wrong on.

Being precise about "no telemetry"

We are not going to claim we collect nothing, because that is not quite what happens, and a privacy company rounding in its own favour is exactly the failure mode we are arguing against.

The desktop app writes a usage log to your own disk. It records that operations happened and how long they took, with no personal data in it. Nothing uploads it, we never see it, and you can delete it whenever you like. It exists so you can debug your own installation, and so a tester can send us something useful if they choose to.

This site runs a self-hosted analytics tool that counts page views without cookies and without following you anywhere. That is disclosed in our privacy policy, and it is a different thing from the app, which sends nothing.

The business case, without the invented statistic

You have read the paragraph that quotes an average breach cost. We are leaving it out, because the number gets copied between blog posts until nobody can say what it measured or where it came from.

The argument stands without it. If your staff are pasting client records into an AI tool today, that is a disclosure to a third party you have not assessed, and it is happening whether or not you have a policy about it. Reducing what leaves the building is a risk decision that does not require a headline figure to justify.

See the principle in the product: download Velum, or read the terms.