← Projects
Amazon Amp icon

Amazon Amp

Amazon's live radio app, where anyone could DJ their own show with a catalog of licensed music and take live calls — built from a functional prototype through launch and Discovery 2.0.

amazonamazon musicreact nativedesign engineeringlive audioiosandroiddesign systems

Amp was Amazon's attempt to reinvent radio: an app where anyone could host a live show, mix in music from a catalog of licensed songs, talk over it, and take live calls from listeners. It launched in March 2022 on iOS in the US as a limited-access beta, with shows from Nicki Minaj, Pusha T, Big Boi, Tinashe, Lil Yachty, Travis Barker, Lindsey Stirling, and radio hosts including Kat Corbett, Zach Sang, and Guy Raz. It shut down in October 2023.

Screenshot 1Screenshot 2
Building a show, and a live show running. Images via Amazon

I joined Amazon Music at the very beginning of the project — while it was still codenamed Project Mercury, before there was an app — as a senior front-end engineer on the Design Engineering team, sitting at the intersection of product design and engineering. I was there from the first functional prototype through launch and the app's largest post-launch redesign.

The functional prototype

Before Amp was a product, it was a question: does this experience actually work? My first job was to build the answer — a complete functional prototype of the app, in React Native, that people could hold and use.

It was a real app, not a click-through. Live audio ran on the Amazon Chime SDK, with a full show lifecycle: creators could schedule and start a show, build and run a playlist against a music catalog, manage participants, and hand the microphone to listeners who dropped in live. Listeners got a home feed, a radio-dial browsing metaphor for skipping between live shows, a persistent play bar and player, creator profiles, and following. State ran through Redux with sagas driving the show, playback, and drop-in flows; data came over GraphQL; and a native bridge connected the JavaScript to the containing app.

That prototype was how the team argued about the product — including the builds that went to leadership for the decisions that determined whether Amp got made at all.

The design system

As Amp moved from prototype to production, I built the shared React Native UI component library the app's feature teams consumed — a typed, tested package rather than a pile of copied components.

It carried the design language as constants — typography, color, spacing, corner radius, icon sizing, breakpoints, animation, and the glass treatment — and a component set built on top: buttons, dialogs and overlays, bottom sheets, list items, pills, toggles, toasts, icons, badges, and the tag family that made live audio legible at a glance (live, ended, elapsed-time, stats, explicit). It also held the animation primitives the brand depended on, including an animated odometer for live listener counts and character-level text animation.

The parts that are easy to skip got real attention: accessibility utilities, dimension and breakpoint helpers, time formatting, and snapshot and unit tests across the component tree. A design system that isn't accessible and isn't tested isn't a design system — it's a style guide.

Discovery 2.0

Screenshot 1
Images via Amazon / TechCrunch

Amp launched with a deliberately bold home screen: a single show card at a time, optimized for sampling audio rather than the standard vertical scroll of a user-generated-content app. It was a real design bet, and the data said it hadn't paid off — a large fraction of new users never listened to or scrolled past the first card they saw. Customers had no way to browse for content matching a mood or an interest.

Discovery 2.0 was the response, and the largest project I worked on at Amp: unify home, search, and a new deep-browse surface into one discovery experience. The single-card home list became a Show Tuner limited to content you could listen to right now — live shows, replays, channels — with a peek at the adjacent card so it read as browsable, and richer metadata on each card. Below it sat Explore: horizontal show and creator carousels, dynamic genre and topic pills computed from what was actually live in the catalog at that moment, a "live soon" list, and vertical browse by category.

The whole thing was structured as parallelizable milestones shipping to customers every two weeks, rather than one large redesign landing at once. Peers described it afterwards as a project that wouldn't have materialized without a relentless focus on shipping it — which is the part I'm proudest of, because the hard problem was never any individual screen.

Working at the seam

The role I actually played at Amp was the one between disciplines. Design Engineering meant turning concepts into working code fast enough that the team could evaluate them live, in a session, instead of arguing about static mockups for a week. It also meant being the person designers and product managers asked what was feasible, and the person engineering teams borrowed for front-end problems across the app.

Press