All articles
PrivacyStudio OriginalFebruary 10, 2026·7 min read

What 'private by default' actually means in a web app

Every product page on the internet says 'we take your privacy seriously'. Most of them mean 'we comply with the minimum legal requirement and we'd love to keep selling your data if we could'. The phrase has been worn smooth. So let's be specific about what private actually means when you're building a web app.

Three levels of private

The weakest version is 'we don't sell your data to third parties'. This is the minimum that GDPR effectively forces, and it's what most consumer apps mean when they say 'private'. They still collect everything they can, they still profile you, they still serve you ads based on your behavior — they just don't hand the raw data to other companies.

The middle version is 'we don't collect what we don't need'. This is harder than it sounds because the easiest way to build any analytics is to log everything and figure out later what you wanted. Choosing not to log a thing means you'll never have that data, which means you have to make product decisions without it. Most companies are not willing to make that trade.

The strongest version is 'your data never reaches our servers in the first place'. This is what local-first apps and in-browser tools achieve. The file never leaves your device, the server has nothing to leak. This is the standard we hold ourselves to wherever it's technically possible.

What it costs to build the strong version

Local-first software is harder to build than server-first. You give up easy analytics, easy A/B testing, easy debugging from logs. You can't see why a user's flow broke because you have no logs from their session. You can't push a hotfix and immediately see whether it worked. Every release feels a little blind.

On the upside, you stop carrying liability. A breach of a server with no user data isn't really a breach. Compliance becomes simple because there's nothing to comply about. Hosting bills shrink because the work is happening on the user's machine, not yours. Once you're past the initial pain, the calmer architecture is genuinely cheaper to operate.

Spotting fake privacy

Open the network tab in your browser dev tools and load the app. Watch the requests. A genuinely private tool will fetch its own assets and maybe a single, self-hosted analytics endpoint, then go quiet. A fake-private tool will fire off requests to Google Analytics, Facebook Pixel, Hotjar, Sentry with PII, three different ad networks, and a 'session replay' tool that's literally recording your screen. The dev tools don't lie.

Read the privacy policy. Search for the word 'partners'. If there's a long list of third parties they 'may share data with', that's the whole answer. Real private-by-default policies are short because there's not much to disclose.

Where MODVC sits

We use minimal analytics — page views and the kind of aggregate counts we need to know whether a feature is actually being used. We don't run third-party trackers. The tools that can run locally do run locally; Convert handles files with automated deletion, and Doodle Type processes your practice sessions entirely in the browser. Mod Player is completely offline on your Android device.

We're not perfect — no one running a real product is — but the architecture is built around 'collect less, store less, share none' rather than 'collect everything and figure it out later'. That's the version of private we mean when we use the word.