Private by architecture, not by promise

The promise model

Most "privacy-first" products are organized around a promise: we collect your data, but we promise to handle it carefully. Sometimes the promise is sincere. Sometimes it survives a change of CEO. Sometimes it does not survive a subpoena. The promise is, by construction, only as durable as the company that made it.

The architecture model

A different approach: build the product so the promise becomes physically unnecessary. No accounts. No telemetry. No cloud sync. Revoke the network permission and the app keeps working. The privacy property is not asserted by a policy page — it is enforced by the absence of code that could ever violate it.

In practice that means:

• No analytics SDK. Not Mixpanel, not Amplitude, not a homegrown event pipeline. The number of users we have is unknown to us, and that is the point.
• No remote configuration. A feature flag is, in our threat model, a backdoor. Every binary we ship behaves the same on day one and day three hundred.
• No background uploads. Logs are local, opt-in, and surfaced only when the user pastes them into a support email.
• No third-party domains. The only network calls a Flux app makes are the OS-mediated ones (App Store updates, system push) — never our own.

What it costs us

• We cannot A/B test in the conventional sense. We rely on small in-house user studies and on listening to support email.
• We cannot fix bugs by inspecting your data. We rely on reproducible local repros.
• We have to ship features that work the very first time. There is no "we will tune this from the dashboard."

What it buys us

• A privacy claim a regulator can verify with tcpdump.
• A user base that does not have to trust us — they can verify.
• A product that ages well, because it does not depend on a billing relationship to keep working five years from now.

The promise model scales the company. The architecture model scales the trust. We picked the second.