RÖST
Case study · 2026 to presentEvery social product of the last fifteen years has been built on the photograph. You decide who somebody is from a square image, in about a fifth of a second, and everything downstream follows from that: the filters, the editing, the performance of a life rather than the having of one.
RÖST starts from the voice instead. A post is somebody talking. You hear how they think, what they find funny, where they are from, how long they take to get to the point. People are more than pictures is the line, and the whole product is an attempt to make that structurally true rather than merely said.
Three modes on one account. Discover is an open audio feed. Connect is dating where nobody sees a face until both people agree to it. Create is where a voice can earn, through commissions, subscriptions and communities. Designed, architected and built solo, from the idea to the store listing. Launching in London for 18 to 25 year olds.
Solo: design, architecture, build and delivery.
Feature complete on Discover and Connect. Closed Android beta next.
Three modes, one account
The productSocial media where the unit is a recording of somebody talking rather than a picture of them. Follow, search, listen, reply in voice.
You hear people before you see them. Each card plays one answer that person chose to record, and liking is held back until at least one has been played.
Commissions, subscriptions and communities, so the people worth listening to have a reason to keep talking.
The interesting problems
EngineeringA face that is never sent
On Connect the promise is that nobody sees you until you both agree, and almost every app that promises this sends the photograph and blurs it on the phone. That is a visual effect: the real image has already arrived, and a blur radius is a number anybody can change. Here the photograph never leaves the server. What travels instead is a blurhash, about thirty characters of averaged colour, so there is nothing on the device to un-blur. The first time a single byte of somebody's face crosses the network is after both people have said yes.
Making a blurred face feel human
Which created a far more interesting problem. Thirty characters of colour, drawn at the size of a phone screen, looks like a gradient, and the card's entire job is to say there is a person here. More detail is the obvious fix and also the privacy dial, so that road is closed. Hard pixel blocks looked like a broken image. What actually works turned out to have nothing to do with the code: it is lighting. A face lit against a dark ground still reads as a face when it is crushed to twenty frequencies, because the warmth and the falloff survive. A flat snapshot in a bright room does not, and no amount of rendering puts the person back. So the light is shaped before the hash is made, and the phone draws something very simple.
Earning the reveal
A photograph unlocks when both people have actually talked: three voice messages each, of real length, not three from one person and silence from the other. Nothing counts a running total, because a total is a number that can be wrong, and being wrong here means showing somebody's face when it should not have been shown. It is worked out from the conversation itself, every time, and worked out again at the moment the reveal is accepted rather than when it was asked for. Both galleries open together or neither does. Saying not yet is drawn as an ordinary choice, and both people can carry on talking.
One account, two lives
Somebody can be a public voice under their own name and a private person on Connect, on one login, with nothing joining the two. The hardest product conversation was the reasonable-sounding suggestion that a mutual reveal should show the full public profile. It should not: agreeing to show your face is not agreeing to hand a stranger your professional identity. Someone who does voiceover work publicly, and dates privately, gets to decide that separately. Linking the two is a switch, off by default, theirs to turn on.
The artwork is the voice
While somebody records, the screen behind them is a live ribbon of particles drawn with Skia, driven entirely by the microphone's own metering. It is not a decorative animation reacting vaguely to sound: the shape on screen is the shape of that person speaking. The same idea carries into the feed, where the waveform on a card is the real envelope of the recording rather than a stock squiggle, captured live while they talked.
Trust that holds up
A dating product for 18 to 25 year olds has to actually know its users are adults, and a date of birth box knows nothing. Platform signals are checked first and verified on the server before anything is recorded, so a device cannot simply assert that it passed. Stronger checks are reserved for the cases the data says need them, which is a decision the product can make with evidence a week after launch rather than by spending money up front on a guess.
The tests run inside the deploy
Worth a mentionA quarter of the database migrations are verification migrations: they create real users, act as those users, call the real functions and refuse to deploy if an answer is wrong. They run against the real database, in the same transaction as the schema they are checking. It is a deliberate choice, because the questions worth asking are not unit-testable ones. Whether a stranger can reach a private conversation through any route at all is a question about the database, not about a function, and the only honest way to ask it is to try.