Gambling Recovery App - Yume

The problem

People recovering from gambling addiction need community and clinical support, and the same stigma that makes recovery hard makes them unwilling to use anything that asks who they are. A service that requires identity filters out the people it exists for.

So the requirement was uncomfortable by design: give someone a real community and a real coach while keeping them anonymous by default and their content private from the server it travels through.

What the platform does

A new user gets a randomly generated handle at onboarding — no identity required. From there, disclosure is progressive and theirs to control: they can reveal themselves to one person, to a group, or to the whole community, and not otherwise.

Around that sits an encrypted community feed with posts, comments and reactions, real-time chat, in-app calling, and coach matching that works without exposing who anybody is. Subscriptions are monthly, yearly or lifetime.

The app is React Native and TypeScript with Redux and React Query, Firebase Auth for phone, Apple and Google sign-in, and a NestJS and PostgreSQL backend on AWS Elastic Beanstalk. Stream provides chat, feed and calls; Virgil Security provides the encryption; RevenueCat handles subscriptions.

What I owned

I worked on Yume as a React Native developer at Inseed, the agency engaged to build it, alongside a mobile lead, a backend engineer and a designer.

My work was the application itself — the React Native and TypeScript client, and the surfaces where the encryption is felt rather than configured: the feed, chat and calling. The encrypted-identity architecture and the NestJS backend were the team's and a separate backend engineer's respectively.

Key decisions

Encrypt before the content reaches the service that carries it. Posts are encrypted client-side with Virgil before they are handed to Stream, and decrypted again on each device. Stream still does what it is good at — delivering a real-time feed and threading comments — but against pseudonymous handles, and the server never holds plaintext or real identities.

The mapping from handle to person is itself encrypted, and unlocks only under the disclosure rules the user set. That is the difference between a product that promises anonymity and one that cannot break it even if it wanted to.

Where it got hard

Encryption moves work to the client, and the feed is where that shows.

Scrolling. Decrypting many posts on device while keeping a feed smooth is real work that a plaintext feed never has to do.

Moderation. When the server cannot read content, the usual moderation levers are simply unavailable — no server-side scanning, no keyword rules. Moderation has to happen on the client and in the community. For an audience this vulnerable that is not a detail to reach for later.

Threading. Comments and reactions attach to pseudonymous handles rather than identities, so conversations thread correctly without any of them naming a person.

What the team would do differently

Lock the identity model first. It touched every feature — feed, chat, coach matching — so anything that changed it late rippled through all of them. Anonymous-by-default with progressive disclosure is a foundation, not a setting.

Budget for encrypted-feed performance from day one. Keeping a decrypting feed smooth is planned work, not an optimisation pass bolted on afterwards.

Design moderation at the start. When the server cannot read content, moderation has to be built rather than switched on, and that is worth knowing before the community arrives.