Social Inbox#

A mobile app that presents your email inbox in the style of a social network — TikTok or Instagram, but for email.

Core premise#

Email clients have looked the same for 30 years: a dense list of subject lines, sender, timestamp. Meanwhile, the apps people actually spend time in (TikTok, Instagram, Reels) have trained users on a very different interaction pattern: one item at a time, full-screen, swipe to dismiss, tap to engage.

What happens if we apply that pattern to email — specifically for users whose inbox is mostly notifications they want to see and forget, not threads they want to act on?

Design notes#

The design was worked through in a grilling session. Each piece below captures one branch of that conversation.

  • Target user — who this is for and who it isn’t.
  • Feed and interaction model — feed shape, cards, scroll-past behaviour, action rail, notifications.
  • Architecture — iOS-first, free tier is pure client, Pro tier adds a dumb-relay backend for push.
  • Monetisation — freemium, no ads, ~$1.99/mo Pro tier framed as “the version that costs the developer money to provide.”
  • Enhancements (deferred) — richer cards, on-device AI summaries, smarter notifications, cleanup rail, multi-account.
  • The Gmail verification wall — the regulatory cost that makes this unviable as a solo side project.

Conclusion#

The design is coherent and the product would be interesting. The v1 we landed on is a pure-client iOS app that polls Gmail in the background, shows a vertical feed of cards with sender + subject + time, has an always-visible action rail (reply, forward, snooze, archive, delete), and raises generic local notifications when new mail arrives. A Pro tier at ~$1.99/mo adds a dumb-relay backend for reliable push, and future iterations layer on richer cards, on-device AI summaries, and a cleanup rail.

This idea is shelved. The Gmail verification wall — a recurring $2-5k/year CASA security assessment plus weeks of compliance work — makes it economically unviable for a solo side project with no personal-use motivation to sustain it through the long pre-revenue period. The math only works for a funded team with runway, and the developer wouldn’t use the app themselves.

What’s worth keeping from this:

  • The interaction model (scroll-past = seen, always-visible rail, single muted “old” stream below the new) is a clean fit for casual email users and could be reapplied elsewhere.
  • The “Pro = the version that costs us money to provide” framing is a useful general principle for freemium pricing.
  • The architecture pattern (pure client free tier, dumb-relay backend only when push is required) is a clean way to keep a small product out of data-controller territory.
  • The filter that surfaced this idea’s incompatibility — the developer would use it themselves, no regulatory toll booth, zero marginal cost per user — is a useful test for future ideas in this workspace.
Target user Forward