Privacy begins before the first screen
It is easy to describe privacy as a collection of controls: a switch for telemetry, a permission setting or a policy explaining how data is handled. Those things matter, but they arrive late if the architecture already depends on constant collection. At NONIVERUS the earlier question is simpler: what data is genuinely necessary for the function to exist?
When an application can process information on the device, work without a compulsory account and avoid servers that add no real value, privacy relies less on promises alone. It also exists in the structure of the software.
Fewer dependencies, fewer exposure points
Local-first does not mean that everything must remain isolated forever. It means the user’s device is the starting point and any movement of data should have a clear reason. Backup, synchronisation or operating-system integrations can be useful, but they should be optional, understandable and proportionate.
That can reduce exposure surfaces and make a product more predictable. If a feature does not need the Internet, there is little reason to create a remote dependency simply because it is common practice.
Privacy still requires engineering discipline
Keeping data locally does not solve every problem. Backups, device loss, permissions, operating-system security and exports all require careful decisions. Local-first is an architectural choice, not a magic word.
That is why we prefer the phrase privacy by architecture: data minimisation, user control and technical decisions that can be observed in how the product actually behaves.
A different relationship with the user
When a business model does not rely on behavioural advertising or selling attention, it becomes easier to align the product with the person using it. The goal can remain solving a need well instead of maximising screen time or collection.
For us, privacy also means building software that can be useful without turning a person’s digital life into raw material.