All work

The Home Depot · Senior Technical Product Manager, Mobile Platform · Sep 2025 to present

Releases that don't wait on a laptop

Building the case and the platform for faster mobile releases, from a shared release pipeline to server-driven UI that skips the app store.

Speed to marketCost to serveRisk

From laptop builds to a shared release pipelineBefore: code freeze while chasing open pull requests, build and sign on one laptop, upload builds to QA and TestFlight, run regression by hand, release monthly. About 10 releases a year, with signing keys on individual devices. After: merge to main with the freeze set by CI, GitHub Actions with shared signing keys, automated tests that catch failures early, automatic distribution to QA and TestFlight, and a goal of weekly releases. One pipeline any engineer can run.From laptop builds to a shared release pipelineThe Home Depot mobile app, iOS and AndroidBEFORECode freezechasing open PRsBuild and signon one laptopUpload buildsto QA and TestFlightRegressionrun by handReleasemonthlyAFTERMerge to mainfreeze set by CIGitHub Actionsshared signing keysAutomated testscatch failures earlyAuto-distributeto QA and TestFlightReleasegoal: weeklyAbout 10 releases a year. Signing keys lived on individual devices.One pipeline any engineer can run. Teams adopted it the day it was demoed.
Diagram by Earl Knight.
  • 58%less manual effort per release, projected for phase oneTarget
  • 80%less manual effort per release at target stateTarget
  • ~40engineering teams share the release process the business case coversReported
How to read the numbers

Every number on this site carries one of four labels, so you can tell a measured result from a goal. Company context, like audience size, only appears as Public with the source linked.

Public
Published by the company or a credible third party. The source is linked.
Reported
My own measured result, as stated on my résumé. The case study describes the method.
Directional
An observed trend without a clean baseline.
Target
A proposed success measure, not a result.

The business stake

Every change to a mobile app, from a seasonal promotion to a bug fix, used to wait for the next app release. That makes release speed a speed-to-market problem for every team that ships through the app, and the manual work inside each release a cost problem. There was also a quieter risk: the keys that sign the app lived on individual laptops.

The problem

A mobile release ran through 17 manual activities, spread across about 40 engineering teams. Code freeze meant chasing open pull requests. The app was built and signed on one laptop. Regression ran by hand. The result was about ten releases a year Directional, and experience teams waiting on that calendar to put anything new in front of customers.

The obvious fix was to release more often. On a process with 17 manual steps, more releases would have meant more manual work, not more speed. The work had to come out of the process first, and some changes had to stop needing a release at all.

My role

I’m the technical product manager for the mobile platform. I built the business case for automating the release process, and I own product planning and cross-team alignment for the platform work underneath it: server-driven UI, the orchestration layer behind it, and the delivery foundations every app team depends on. Engineering and DevOps build and run the pipeline.

How we thought about it

I started with a baseline instead of a solution. I mapped each of the 17 manual activities in a release and estimated the effort each one took, so the case for change rested on the work we actually did, not on what a tool promised.

That baseline pointed at three drivers Directional:

  • Build, signing, and distribution done by hand on individual machines.
  • Regression run by people instead of tests.
  • Freeze rules enforced by chasing people instead of by the pipeline.

So we phased it. Phase one moves build, signing, testing, and distribution into GitHub Actions. Target state adds a managed mobile CI platform for the rest. Each phase has its own projected savings, so the business can fund the first step on its own merits.

Server-driven UI came from the same question asked differently: which changes should not need a release at all? If the server composes a screen from a shared component library, a marketing banner can go live without an App Store review.

AI and data

This story is more data than AI. The business case is a model of the release process, built from activity-level effort estimates across about 40 teams. The quality check is built into how the numbers are labeled: the savings are projections, shown here as targets, until phase one produces measured hours per release, release frequency, and build failure rate.

Server-driven UI is also the foundation for personalization. Once screens are composed on the server, what a customer sees can change with data, without a new build.

What shipped

The release pipeline is pictured at the top of this page: one pipeline any engineer can run, which teams adopted the day it was demoed.

Server-driven UI: change the screen, skip the app releaseMarketing and product teams create banners, promotions, and personalization. A backend for frontend server composes each screen from components. A shared component library, designed with the design team and mapped to native code, renders natively in the iOS and Android apps. Changes ship from the server, stay consistent across both platforms, and banners go live without an app release.Server-driven UI: change the screen, skip the app releaseHow a marketing banner reaches the app without an App Store reviewMarketing and productbanners, promotions,personalizationServer (BFF)composes each screenas componentsComponent librarydesigned with design,mapped to native codeiOS apprenders nativelyAndroid apprenders nativelyFasterChanges ship from the server.ConsistentOne set for iOS and Android.PersonalBanners go live without a release.
Server-driven UI: the server composes each screen from a component library designed with the design team and mapped to native iOS and Android code. Diagram by Earl Knight.

Outcomes

Results so far

  • One release pipeline any engineer can run, with signing keys moved off individual devices and into the pipeline. That removes a single point of failure from every release.
  • Business case built for a release process spanning about 40 engineering teams and 17 manual activities Reported.
  • Faster content changes through server-driven UI, since banners and promotions no longer wait for an app release Directional.

Proposed success measures

  • Manual effort per release down 58% in phase one Target, and 80% at target state Target.
  • Weekly releases, up from about ten a year Target.
  • Measured by hours per release, release frequency, and build failure rate once phase one actuals exist. When they do, the 58% becomes a Reported result and leads this page.

What I’d do differently

I would instrument a few releases before the first pipeline demo. The business case rests on estimated effort per activity; measured hours from the old process would have let phase one report a result on day one instead of a target.

Contact

Have a good problem? Let's talk.

Senior product, product strategy, and AI product roles, plus advisory work. I answer every note.