Roger was an asynchronous voice communication product I helped build in 2015 and 2016. I joined early, as the fifth employee, and owned Android end to end: product development, architecture, design input, R&D, release work, and the technical decisions needed to turn an idea into a product people could actually use.

What drew me to Roger was not only the stage of the company, but the nature of the bet. We were not adding voice to an existing messaging product. We were asking a more fundamental question: what happens if voice becomes the center of the experience rather than an auxiliary feature? That framing shaped nearly everything I worked on there.

My Work

Roger’s core premise was simple to describe and difficult to execute well: make everyday communication feel more natural by treating voice as the primary medium. That meant product work at several levels at once. We had to think about intimacy, responsiveness, delight, playback quality, recording latency, accessibility, and the kind of interaction patterns that would make voice feel immediate rather than cumbersome.

Below are the parts of that work that stayed with me most clearly. They are not the complete story of Roger, but they capture the combination of product curiosity and technical rigor that defined my time there.

The Human Touch

One of the strongest product questions behind Roger was how to preserve some of the texture of in-person conversation inside a mobile app. We spent a lot of time exploring what makes communication feel alive rather than merely functional, and how software might recreate some of that feeling without becoming gimmicky.

One expression of that idea was the ambient quality of the interface. The app background shifted from day to night and reflected the weather conditions in the other person’s location. The logic behind it was simple: in casual conversation, people often anchor themselves in the immediate moment, and weather is one of the easiest ways that happens. Instead of treating the interface as static chrome, we used it to make communication feel situated and more human. We also invested in the craft of those transitions, including animations for rain, snow, and clear skies. I built several of the initial launch animations for the iOS app in SpriteKit during that period, and I still think about how much expressive leverage a good animation framework can provide when used carefully.

Audio Engineering

The most technically distinctive part of Roger was the audio stack. The product only worked if voice quality felt immediate, clear, and worth listening to. That meant we could not accept the usual trade-offs around recording latency, processing quality, and payload size.

I built the recording pipeline directly on top of Android’s lower-level audio APIs so we could encode audio on the fly and shorten the delay between pressing record and actually capturing sound. Many apps at the time either accepted that delay or worked around it by keeping the microphone hot and trimming the result afterward, which is a poor trade-off for both battery life and system behavior. I spent a significant amount of time tuning the pipeline to find the right balance between fidelity, responsiveness, and upload cost. The result was audio that users consistently described as meaningfully better than the muffled or robotic alternatives that were common in voice products then.

I also explored binaural recording as a product and technical experiment. Smartphones already expose multiple microphones for call quality and noise suppression, and working at the lower levels of the stack makes it possible to treat those sources more directly. That led to an interesting extension: active noise-cancelling headphones often have microphone placement that is better suited to stereo capture than a phone itself. I built and shipped that capability as a proof of concept. It reached only a small subset of users at the time, but it was a useful example of the kind of exploration Roger encouraged.

Playback had its own challenges. We used ExoPlayer as a foundation, and I extended it with in-house components for audio processing and continuous listening behavior. The larger point, though, was not the choice of library. It was that the entire product was designed to make audio feel like a first-class medium rather than a compromise.

Accessibility

Roger’s first MVP shipped with basic accessibility support from the start, mainly by ensuring that visual elements exposed meaningful labels and that the interface avoided unnecessary concealment behind complicated menus. As the product found users, one thing became increasingly clear: visually impaired users were especially excited by what Roger made possible. In hindsight that made sense. By constraining the medium to voice, we had accidentally created a communication product that already aligned well with users who preferred or depended on audio-first interaction.

I decided to push that further. I worked directly with visually impaired members of the Roger community to understand where the product was already strong and where it still created friction. That work was rewarding not only because it improved the product, but because it widened my understanding of what mobile interaction design can miss when it assumes a primarily visual user.

That collaboration later led to a talk I gave at an accessibility meetup in New York, and to a Medium article about what I learned in the process: Android App Accessibility at Roger. More importantly, it reinforced something I still believe: accessibility work is often where product clarity and technical discipline meet most clearly.