Why Privacy-First Apps Matter (And How We Build Them)

“Privacy-first” shows up on a lot of app store listings as a marketing phrase. It’s worth being specific about what it actually means as an engineering decision, because the difference between claiming it and actually building it is entirely visible in the architecture, not the copy.

Privacy-first is an architecture decision, not a policy document

A privacy policy describes what a company says it does with your data. A privacy-first architecture makes certain categories of misuse structurally impossible, regardless of what any future policy says — because the data was never collected, never transmitted, or never stored anywhere the company itself can access. The distinction matters because policies can change, companies can be acquired, and data that exists somewhere can eventually leak or be subpoenaed; data that was never collected has none of those risks.

What this looks like concretely

Concretely, a privacy-first app makes specific, checkable claims:

• No account required — if there’s no login, there’s no account database that can be breached, and no way to link app usage to an identity in the first place.
• No analytics or telemetry that leaves the device — usage data, if collected at all, stays local rather than being sent to the developer or a third-party SDK.
• On-device storage and processing — the app’s core function works entirely locally, so there’s no server round-trip where data could be intercepted, logged, or retained.
• Secure enclave for genuinely sensitive data — secrets (passwords, cryptographic keys, 2FA codes) stored using the platform’s hardware-backed secure storage (iOS Keychain, Android EncryptedSharedPreferences), the same protection tier used by password managers and banking apps — not just “encrypted,” which can mean very different things in practice.
• No third-party SDKs with their own data collection — many “free” analytics or crash-reporting SDKs collect and transmit more than developers realize; a genuinely privacy-first app audits (or simply avoids) these.

A case study: Caddy and Authenticator Exporter

Both of Elmeris’s own apps are built this way, not as an add-on but as the starting architecture. Caddy, a text snippet library, syncs across your devices through your own iCloud or Google Drive account — not through Elmeris’s servers — meaning your snippets never pass through infrastructure we control at all. Authenticator Exporter decodes and stores your 2FA secrets entirely on-device, in the platform secure enclave, with the app functioning fully offline — there is no server for it to talk to, by design, not by promise.

In both cases, if a subscription lapses, previously-stored data stays exactly where it was — data is never held hostage as a retention tactic, which is itself a privacy-adjacent commitment: your data isn’t leverage.

Why this is a deliberate business choice, not just a technical one

Building this way forecloses entire categories of monetization — you can’t sell data you never collected, and you can’t build an ad-targeting business on usage patterns you never tracked. The trade-off is real: these apps monetize through subscriptions rather than data, which is a slower, less lucrative model than the data-driven alternative. It’s also, we think, the only version of “privacy-first” worth the name — one that’s structurally true rather than a claim that happens to be convenient to make today.

See how this plays out in each app’s own privacy policy: Caddy and Authenticator Exporter.