Audible is the largest audiobook platform in the world, and by the time I joined in 2017 it was already operating at a scale where even small architectural decisions had long consequences. I joined the mobile organization as part of the team responsible for the main Android and iOS applications, with a focus on Android systems work, product delivery, and the parts of the app that had become hardest to evolve.

This is not a full account of everything I worked on there. It is a selective account of the work that best represents how I tend to operate: stepping into difficult systems, improving their structure, and helping teams move faster without lowering the quality bar.

My Work at Audible

Across roughly two and a half years, I worked on infrastructure, product features, and platform integrations. Audible’s mobile organization was large enough that priorities shifted regularly and teams were often reorganized around new initiatives, so the shape of the work changed over time. What remained constant was the need to make complex parts of the Android app easier to reason about, easier to ship, and safer to extend.

Library Rewrite

The most important project I led at Audible was the rewrite of the Library stack on Android. By "Library", I mean not only the screen that lists audiobooks, but also the sorting and filtering flows around it, the network layer behind it, the persistence model, and the local data structures that supported offline behavior and caching.

The immediate trigger was a cross-functional initiative to design a new REST API for library endpoints. I was pulled into that effort alongside another senior Android engineer to represent the needs of the mobile clients. My initial scope was to help shape the API and rethink the networking layer on Android. Once I examined the state of the existing implementation closely, it became clear that a partial cleanup would not be enough. The library had become one of the most fragile parts of the application, and every meaningful product change inside it carried disproportionate risk.

The old implementation had accumulated years of technical debt. Core classes had grown to enormous size, responsibilities were tightly coupled, and the model layer had been stretched to represent too many different content types with too little clarity. The local database was similarly difficult to maintain: denormalized, hard to reason about, and full of structural compromises that had made the code slower to change and easier to break. When engineers tried to document the existing system ended up producing maps of complexity rather than useful abstractions because of the inherent fragile state.

At roughly the same time, I had also been asked to help size an upcoming UI rewrite for the Library. Seeing the feature roadmap and the underlying system constraints together made the decision easier: if we did not address the architecture first, the next wave of feature work would be slower, riskier, and more expensive than it needed to be. I proposed a full rewrite, management approved it, and we committed to rebuilding the Library in a way that would let the rest of the app keep moving while the transition was in progress.

The architectural challenge was not only to build a better system, but to do so without stalling other teams. Several mobile efforts depended on library data in one form or another, and the new backend API would not be ready for months. To manage that, we first introduced a set of interfaces that decoupled the rest of the app from the old library internals. That gave us a functional bridge: we could continue shipping, replace the underlying machinery incrementally, and avoid forcing parallel teams into premature rewrites of their own work.

We also introduced cleaner value objects with narrower, more intentional contracts between data and UI. Instead of carrying a handful of overloaded models through the system, we moved toward types that expressed purpose more clearly and exposed only what a given surface actually needed. From there, we rebuilt the internals around pagination, parallel fetching, a saner persistence model, reactive flows, and an MVVM-like structure with clearer separation of concerns.

The outcome was substantial. For customers with very large libraries, load times dropped from roughly eight minutes to under five seconds. The biggest wins came from pagination, parallel fetching, and HTTP/2 adoption, but the deeper value was that the system became understandable again. Bug incidence in the library dropped by roughly a factor of three, and a team that had estimated a follow-on UI feature at three and a half months was able to ship after about fifteen days once they were working on top of the new architecture.

Elevating the Team

One thing I cared about at Audible, beyond my formal project scope, was raising the baseline of the Android codebase and helping the team move toward more modern practices. Much of the app was still shaped by an older architecture that made development slower and less predictable than it should have been. Even strong engineers and a dedicated QA function were working against structural friction.

Part of my contribution there was to help create momentum for better technical choices. One early example was pushing for the adoption of Kotlin. The technical case was straightforward, but getting a large organization aligned around change took time. That work involved conversations across distributed Android teams, coordination with adjacent Amazon groups, and collaboration with security and compliance stakeholders. It was less glamorous than feature work, but it mattered because it improved the long-term leverage of the team.

Hackathons

Audible was also a useful reminder that innovation in large organizations often needs a different venue. The company’s main product strategy at the time was understandably conservative and heavily focused on catalog strength, so internal hackathons became one of the better places to explore new ideas, collaborate across functions, and test concepts that would not have emerged through the normal roadmap. I took part in four of them and placed first in two. One of those ideas later influenced production work.

Other Work

Outside the larger rewrite, I also owned the implementation of App Indexing on Android. Under different circumstances that would have been a fairly routine task, but Amazon’s aversion to third-party dependencies, including Google libraries that could potentially send data over the network, made the implementation path unusual. I ended up piecing it together through a mix of system-level investigation, reverse engineering, and direct collaboration with Google engineers.

I was also frequently pulled into audio- and security-adjacent work, both because of my prior background and because I tend to gravitate toward systems that are hard to get right. More generally, what I valued at Audible was the range: one product, many surfaces, and a broad set of technical constraints. In addition to the main Android app, I worked across Kindle and Alexa integrations, car surfaces such as Android Auto and dedicated in-app car mode, and Fire OS support for Amazon’s tablet and TV devices.