Back to Portfolio

Patreon

An account of Android performance, reliability, native video, and engineering leadership during Patreon's pandemic-era growth.

Patreon company logo

I worked at Patreon from 2020 to 2022. I joined right as the COVID-19 pandemic was in full swing and tech had gone fully remote, and as the company was growing fast: more creators, more patrons, and more economic weight behind the platform. A lot of that growth traced back to the pandemic. People were home, live shows and concerts were cancelled, and Patreon filled a real market need at the right moment.

This isn’t a full account of everything I did there, just the work that best shows how I tend to operate: stepping into systems that have outgrown their original assumptions, making them faster and easier to reason about, and helping a small team do more than its size suggests.

The state of Patreon during my tenure

Patreon started as a web product. People reached it primarily on a computer, and when I joined, web was still the dominant surface by usage. But mobile was gaining momentum quickly, especially among younger users, and a better mobile experience consistently ranked among the top requests from creators and patrons. Becoming mobile-first was a stated company ambition, but not yet a reality.

The company was also going through growing pains. Patreon had defined a new way to monetize in the creative age, and being at the front of that meant there was no playbook: the product kept questioning and reinventing itself. That left a steady accumulation of legacy features and architectural decisions to account for every time we wanted to evolve the system. That part felt familiar, since it was the same reality I had dealt with at older, more established companies.

What felt different was the size. After one of the company’s periodic reshapings, Patreon ran as a deliberately small organization where everyone had a lot of autonomy. In many ways it felt like an early-stage startup again, partly because the people there cared so much about the mission. I did well in that mix of autonomy, constant judgment calls about what actually mattered at each stage, and a rising bar for craft as we leaned into mobile. My scope grew with it. I owned the direction of Android development, reported directly to the company’s CTO, and became a key player in hiring across technical roles, not just on mobile.

Performance and Reliability

When site stability became a company-wide concern, I stepped into the mobile performance work and ended up owning most of it on Android. The problem had two halves. The app had real performance issues, with patrons complaining about a slow Feed and creators about slow Notifications, and we had almost no way to measure what was actually happening.

So I started with measurement. I ran a research spike into both apps’ network consumption, worked with the Data team to find our highest-traffic flows, and turned the findings into prioritized work. Removing redundant calls cut roughly 75 million network requests per month, while HTTP/2 and a shift to WebP images reduced payload sizes and image download times. I also rebuilt enough of the networking and persistence layers, with better caching and a saner eviction policy, to make the Feed load and render about twice as fast, and brought our cold compile time down from 6 minutes to 2.

Chart showing mobile app image download load time improvements across app versions
Average mobile image load times improved dramatically over a few app versions.

The reliability work mattered just as much. I introduced a non-fatal exception logging pattern that took us from essentially zero visibility to around thirteen million non-fatal touchpoints a month in Firebase, which surfaced broken flows we previously had no way to detect. I added Datadog RUM and alerting that pinged the team on Slack the moment a critical flow regressed. And I started a bi-weekly Android Bug Hunt, where the team triaged top crashes and turned them into real tickets, with an aggressive target of 99.5%+ crash-free sessions, up from around 94%. We hit it. Together, the performance and reliability work contributed to roughly a 30% lift in retention among monthly active users and a 20%+ increase in daily engagement.

Patreon 2.0 and foundations

A good portion of my time went into the parts of the codebase that decide whether every future feature is cheap or expensive to build. I re-architected our core flows, Messaging being the clearest example, onto an MVVM structure with dedicated value objects that carried only what a given screen needed, instead of dragging overloaded models through the whole system. It came with real testing discipline: messaging UI coverage went from 18% to 37%, and the data layer to 84%, on flows that previously had almost none.

Studio Samples app showing reusable UI controlsEarly Patreon Dark Mode support in the Studio Samples app
Studio Samples was an internal app I built on top of the modular UI foundation to exercise components in isolation; to the left is an early version of Dark Mode Android support for Patreon.

Underneath the product work, I drove a steady modernization effort: a rotating cadence for keeping dependencies current, memory-leak detection, and an in-app debug menu that could switch environments on the fly, which later helped other teams with things like mobile account impersonation for support. For the Patreon 2.0 redesign, a ground-up overhaul of the app’s look and design system, I pushed to separate the UI into a modular design system so components could be reused and iterated on more easily, as well as tested in isolation by design. Much of that foundation is invisible from the outside, and that is partly the point: it made the app easier to reason about, so the next wave of product work could move faster without dropping the quality bar.

Patreon 2.0 also paid off where users could see it. It noticeably raised the perceived quality of the app, with a more modern look, the introduction of dark mode, and a level of polish it hadn’t had before. The reaction was bigger than I expected: praise in the press, enthusiasm from users on social media and in Patreon’s own Discord, and a lot of excitement internally. It also opened the door to harder foundational work that came after, like new navigation patterns for cleanly separating the creator and patron profiles that can sit behind one account.

Feature wall showing Patreon 2.0 workstreams
A feature wall showing some of the larger Patreon 2.0 workstreams I contributed to.

Native Video, and what the data taught me

Patreon’s first native video experience started as a hackathon project. There was clear interest, so I built it into a properly crafted mobile experience: picture-in-picture, HLS streaming, and the playback details that make video something people actually want to use rather than a merely supported file type. What started as a side experiment grew into one of the app’s core consumption formats, a primary way many creators delivered to their audiences. I also led several research spikes and proofs of concept to test longer-term mobile strategy options, then became the point person for explaining that rationale across engineering.

Working this closely with the Data team was one of the unexpected pleasures of Patreon. I sat in regular sessions going through insights, and that’s where I came to understand the product more holistically. Before joining, I thought of Patreon as a home for the art forms I already knew: music, podcasts, comics, education. What I learned was how many niches lived on the platform, and how large they were. Game modding, cosplay, religion, open-source software development, and plenty of things most people would never associate with Patreon. Each niche had different needs. Some lived on video, some on audio, some on files, some almost entirely on peer-to-peer messaging, and it was never obvious in advance which would thrive. It was a real lesson in niche economics, and a reminder of why the mobile surfaces we were building had to be flexible enough to serve all of them well.

Elevating the team

The last thread that ran through my time at Patreon was the team itself. As we scaled, I became a Hiring Excellence member, helped revamp the interview process, designed scorecards and the domain portions of the mobile loop, and did a lot of interviewing, shadowing, and mentoring across levels, which helped staff up the Android team during an aggressive hiring push. I cared about raising the team’s baseline as much as shipping any one feature: pair-programming sessions, internal Mobile 101 onboarding material, and a steady habit of presenting the mobile team’s work to the wider organization so the rest of the company could see what we were building and why it mattered. The combination of intentional work, real autonomy, and people who cared so much about the company’s mission is still what I think about most when remembering my time there.