A weekly release train that kept slipping
Posh is a social marketplace for real-world experiences, helping organizers create, scale, and monetize communities through events. Its mobile app serves millions of users across iOS and Android, which meant every release had to go out safely, reliably, and on schedule.
For two years, that meant a manual weekly release process. Someone on the team had to take a turn as the rotating Release Train manager, responsible for shipping that week's set of changes by hand. David Davidov, a Founding Engineer at Posh, has called this the team's biggest bottleneck: a recurring, person-dependent chore that made mobile development feel less like building and more like babysitting a release checklist.
The team also lacked visibility into which app version a given ticket actually shipped in, had no reliable way to tell whether a pull request introduced native changes, and was stitching automation together with GitHub Actions that required constant upkeep. Individually, none of these were catastrophic. Together, they added enough friction that the team decided to rebuild the release pipeline from the ground up.
Rebuilding release automation around fingerprinting and EAS Workflows
Posh's redesign centered on two Expo capabilities: fingerprinting, which detects whether a given commit introduces native code changes, and EAS Workflows, which run automated jobs (builds, submissions, notifications) triggered by events like pull request merges. Together, they let Posh's team tell, automatically, whether a change could go out as a JavaScript update or required a full native build and store submission.
The team split its automation into a few connected pieces. PR preview workflows post a QR code on each pull request so engineers can install and test changes on a development build immediately, and PRs get labeled automatically when they introduce native code. OTA branches collect JavaScript-only changes merged to master, publish them to a staging environment for testing, and only push to production once that branch is merged. This kept changes merged to master from deploying to production automatically. Version branches take over when a native change lands: they close out any open OTA branch, bump the app version, and become the source of truth for whether a store release is needed.
Builds and store submissions still require a manual label before they fire, so Posh doesn't burn build credits or trigger submissions before the team is ready. The final manual step in the whole pipeline is submitting to app review and clicking release, which Posh deliberately left as a human decision because a store submission can include more than just the updated bundle.
Posh also built a notification layer on top of this: when an OTA or version branch merges, a GitHub release fires with an auto-generated changelog, a Slack message tells the team what shipped, and every associated Linear ticket gets tagged with the version number. That closed the original visibility gap. Anyone on the team, including PMs and support, can now see exactly which version a given ticket landed in.
Monthly store releases, multiple OTA updates each week
With this pipeline in place, Posh moved from weekly manual store releases to nearly monthly store releases, supplemented by multiple over-the-air JavaScript updates per week for changes that don't touch native code. The rotating Release Train manager role, previously the team's biggest bottleneck, is gone.
David Davidov has said the improved release velocity helped support Posh's growth to the number one app in the Entertainment category on the App Store, and has credited Expo's fingerprinting and workflow tooling as a key part of getting there. Posh's own account frames this as one contributing factor among others behind that chart position, not a sole cause.
The implementation
The underlying lesson generalizes past Posh's specific setup: a release pipeline that can tell the difference between a native change and a JavaScript-only change, automatically, is what makes it safe to automate the rest. Once that detection is reliable, batching OTA updates, gating builds behind a manual label, and notifying the team on release stop being manual chores and become steps a workflow runs on your behalf.
“This automation helped us go from weekly manual releases to nearly monthly store releases and multiple OTA updates a week!” (David Davidov)
Sources
How Posh went from manual weekly mobile releases to continuous delivery with Expo (2026-07-23)
