Founded in 2014, PrizePicks is the largest daily fantasy sports organization in North America. It consistently ranks among the top five most downloaded sports-related apps on the App Store and Play Store.
PrizePicks first builds its app for the web and then converts its web code to native iOS and Android binaries using Capacitor, with a goal of continual feature parity across every platform. 85% of PrizePicks users are on mobile, so it’s very important that their releases go very smoothly and that updates don’t harm the mobile app experience.
Millions of customers are using the app at any given time, with big usage spikes during weekend sporting events (which would also be when disruptive issues are most annoying and difficult to fix). The PrizePicks engineering team knows how important it is to run a smooth release train that gives the entire team easy insights into everything going on with each release.
Having one person manage every release isn’t scalable
PrizePicks has seen explosive growth in recent years. Beyond broadly growing their customer base, over the past four years their engineering team has grown from 4 people to well over 150, with 10 different feature teams contributing to the core app. Since they build one app and convert it to multiple platforms, there is no separation between teams working on web and teams working on mobile. Everyone is contributing to everything.
“There has been one constant for mobile throughout all of this growth, from way back in the early 4 engineer days up until very recently: mobile releases have been managed by a single person.”
Ziyan Prasla
Software Engineer
In theory, having one person manage releases throughout all this growth isn’t unreasonable. Releasing an update to your app is releasing an update to your app, right? Whether it contains code from four engineers or four hundred, the specific steps required to upload a mobile app update to both major stores and then roll it out to users don’t change much. And Ziyan knows what he’s doing, which helps the technical side of the process run smoothly. His normal routine was to go in and build the app manually, compile a list of everything going into the release as best he could, communicate on Slack that the release was happening, submit it for review, usually get approved, and release it. It was a lot of manual work to do, but so long as he had the time, he could handle it..
The problem, of course, is all the other stuff that had to happen — to orchestrate the people and moving parts needed to get the update ready to go out, and to monitor rollouts for problems once it was uploaded and approved. The more engineers submitting code for each release and the more PMs trying to get their features out the door, the more potential for chaos and confusion every time an update was released. Ziyan could easily handle the technical workflow side of the release, but being solely responsible for getting hundreds of people's work over the line meant he began to get bombarded with questions every single week.
“All these people from different teams, engineers and PMs, would come in and say, ‘Did my code make it in? Did this feature get updated?’ I spent a lot of time backtracking and digging through Slack to get this information, and there was no organization around it. It was kind of the wild, wild west.”
Ziyan Prasla
Software Engineer
To try to get the problem under control, they introduced more structure into the release cycle, starting up a weekly release train. They set a Friday cutoff to get code in, and the app was submitted the next Tuesday or Wednesday. It was helpful to have more structure and better-defined deadlines, but this didn’t actually solve the problem. All the work still had to be orchestrated, and Ziyan was still fielding tons of questions from dozens of people during each release.
“Hey Ziyan! Is this new version of the app approved? Hello, Ziyan, are you there? Why did this get rejected? Ziyan, how many users has the app rolled out to?”
Ziyan Prasla
Software Engineer
This was clearly unsustainable, and while they could train a few more people to help manage the releases, it wouldn’t address the root issue. Instead, it would just push things off to a rotating crew of release managers who would all have to deal with the same questions and digging for information. And that wouldn’t provide faster answers for all the engineers and PMs who need to know the status of each release to manage their own part in it.
The real issue wasn’t a lack of structure, it was a lack of visibility. Which Ziyan and a few other members of the team set out to fix.
Provide teams with a single source of truth, so anyone can see how a release is going
Their next attempt at a solution was a bit better: automated Slack notifications. Whenever they had builds go up or made a major change, they had a fastlane automation set up to ping Slack. This kept stakeholders informed of some of what was happening without Ziyan having to personally take the time to talk to them.
But we all know how this can go. Slack and Teams are both very nice for one-to-one communication and team discussion/brainstorming, but flood them with too many automated notifications, and most people will simply start ignoring the noise. If most notifications aren’t relevant to what you need or what you’re looking for, then you likely won’t be looking at any notifications at all (let alone the relevant ones). In fact, it’d be kind of weird if you were tuned in for all of them.
“Obviously, when you have Slack channels filling up with automated messages like this, things get pretty convoluted. People tune them out and stop looking at them.”
Ziyan Prasla
Software Engineer
When this didn’t fully solve the problem, they started adding release tags to GitHub and attempted to manually keep things clearly labeled there. But doing this by hand was extra work and also easy to sometimes forget. Plus, the shared codebase deployed to web, iOS, and Android wasn’t always perfectly in sync, and at times it could be hard to pinpoint why something was on iOS and not on Android or vice versa.
Frustrated, Ziyan and team felt that there had to be some kind of external solution, so they started Googling. On one of those searches, Runway came up.
“Runway caught our eye because right away we saw it could solve one major problem we couldn’t fix: observability. People didn’t know what was happening, and this provided a one-stop shop where they could see everything and even step in to manage the releases on their own.”
Ziyan Prasla
Software Engineer
By providing a central dashboard that connected to every tool in their release workflow, Runway could bring all the disparate sources of information together — from CI/CD to VCS to project management to Slack to the app stores — in one place, where anyone in the entire org could keep an eye on progress and get answers to any of their varied questions about how a release was going just by glancing at Runway. This would mean no more piles of Slack notifications, no more needing to remember to tag everything in GitHub, no more confusion about what was on iOS, what was on Android, what was on both, what was on neither, and what needed to be done to address any issues with them. It would all just be right in front of everyone.
This would also mean that every team member could see what was happening and could contribute as needed, no longer needing to rely solely on Ziyan to guide them through releases. They could solve their visibility and awareness problems, and at the same time, evolve and modernize their entire release process so that it wasn’t reliant on one person.
A central, single source of truth, equally accessible to — and usable by — every engineer and PM
“I went on vacation last week and it was the first time in four years I didn’t have to be involved in a release at all. That was really cool! It’s been a big weight off my shoulders.”
Ziyan Prasla
Software Engineer
Thanks to Runway, PrizePicks’ releases are no longer managed solely by Ziyan. His years as the knowledgeable, lone release wizard overlooking everything from his tower are over. Information about releases is now available to everyone through Runway (which does not charge per seat), and when appropriate, control over those releases is available thanks to customizable action items and sign-offs, as well as robust permissions and access controls.
So, Runway as a central tool for managing the entire release process doesn’t just mean that engineers and PMs no longer have to ask questions about releases. It also means they can help manage those releases without turning to Ziyan. They can get immediate clarity if something is out on iOS versus Android and easily pull hotfixes into one, the other, or both with immediate clarity on when and where action is needed. Having centralized visibility into the entire process means there’s no more digging for answers, no more confusion about the status of a release, and no more chaos.
One example of how this works in practice: PrizePicks has to be careful about what they’re releasing, as crashes or other problems with their app health can cause immediate drops in revenue. Their QA team thoroughly tests every release, and thanks to the Runway TestRail integration, everyone can centrally see what test cases were run and what passed, failed, was tested again, and still needs to be tested. There is complete clarity, so nothing ever slips through the cracks.
“Runway gave us the freedom to think differently about releases. Instead of always rushing to get all the manual work done with every release, we’ve been able to focus on implementing best practices — like choosing a better branching strategy — that we learned from their docs, their blog, and simply from using their platform.”
Ziyan Prasla
Software Engineer
With Runway now in house to support their release cycle, PrizePicks has had more time to step back and think about their process. They’ve had the flexibility to not just solve their original visibility problem but to make improvements that they never would have had the time or inclination to take action on otherwise, evolving their processes to bring every engineer and stakeholder closer to their releases. Instead of each release being some arcane process hidden away from sight, they’re now seamlessly embedded into everyone’s workflows and are a natural part of their weekly work.
“I don't know why you wouldn't use it. It's almost too good to be true. It’s really easy for everyone to use.”
Ziyan Prasla
Software Engineer
