Privacy-first social app case study: Blured, from whiteboard to 12,000 users

Blured set out to prove that a social app could be private by construction and still feel alive. We joined at the whiteboard stage — no product, no code, not even a shortlist of platforms. A year later we handed back a working app with 12,000 beta users. This is how that year went.

The first two months were mostly saying no

The most important thing we did in weeks one through eight was cut features. The founders arrived with a Notion of 140 pages. We shipped the first beta with exactly four user-facing features. Everything else had to justify its inclusion against the risk it added to the threat model.

Building privacy as a primitive, not a feature

Privacy is not a CSS class. We designed the data model so that the default visibility of every piece of content was the narrowest possible scope, and widening it required deliberate action. End-to-end encryption was not an opt-in — it was the only option. On-device classifiers handled content moderation where possible, so raw content never left the phone.

What we got wrong in the first onboarding

Our first version of onboarding spent too much time educating users about the threat model. Nobody cares about your threat model on minute three of their first session — they care whether the app is pleasant. We stripped the explainers and moved them to a dedicated "how we keep you safe" section. Completion rates doubled.

Where Blured is now

Out of beta and in general availability. Retention in the 40th-percentile of consumer social apps — respectable, but not the point. The point is that retention is from users who chose the app because of its defaults, not in spite of them.