Looking back at their past releases, respondents estimated that better comms, process, and collaboration across releases could have prevented 63.1% of the uncaught incidents in their previous releases—quantifying the massive potential ROI in both recovered engineering time and improved user experience that comes from addressing the coordination gap.
Even the most conservative respondents (8%) acknowledge that better coordination would have prevented some incidents in the past—providing engineering leaders at all maturity levels with evidence that investing in release coordination delivers tangible benefits regardless of starting point.
These findings create a clear connection to earlier data on frequency and incidents: A better, more efficient mobile release management approach would meaningfully improve the quality of shipped work. It's not just about efficiency—it's about delivering a better product to the market and a better experience to your users.
Figure 13: Incidents prevented by a more transparent, centralized release process
Mobile engineering teams clearly recognize the ROI potential of better release management, but many remain locked into fragmented status quo approaches without a clear path forward.
Two-thirds of respondents agree that improving centralized release coordination would have a significant (19%) or at least moderate (47%) impact on their processes.
Nearly everyone (98%) agrees that better release coordination makes teams more efficient—providing practitioners with clear evidence that addressing this challenge isn't just an engineering convenience but a strategic business priority.
The 19% anticipating "extreme" benefits from improved coordination represents teams that have experienced the true cost of fragmented processes. For engineering leaders, this highlights an opportunity to transform their mobile development capability through unified release management that treats the entire process as a first-class concern rather than an afterthought.
Figure 12: Potential impact of improvements in centralized release coordination
Managing releases on an org level takes more than just a strong tooling set. Teams need to improve not only the efficiency of technical steps but ensure smooth communication and status updates across different teams and organizational levels. We see this clearly play out in the data with most organizations relying on general-purpose tools like project management (81%) and communication platforms (68%) for release coordination.
For practitioners, the mix of Jira/Asana (81%), Slack (68%), CI/CD tools (53%), and spreadsheets (47%) creates the very context switching burden they identify as a top frustration—proving that adding more tools to the stack without proper integration compounds rather than solves the problem. It's the thousand-tabs problem that every mobile engineer knows all too well.
The 30% using custom-built internal tools highlights both the recognized need for specialized release coordination and the significant engineering investment required—creating systems that often become technical debt when their champions leave the organization.
These answers underscore the importance of managing releases with humans in mind, not just code—and doing so in the simplest way possible.
Figure 11: Top solutions used to centralize release coordination
Question allowed more than one answer and as a result, percentages will add up to more than 100%
While 75% of teams invest significantly in release automation, most face release friction due to fragmentation and coordination gaps between automated components, not lack of automation.
The majority (48%) of respondents have invested a moderate amount of resourcing to achieve partial automation and are now at an impasse: commit fully to a constellation of tools/custom options, or pivot before the web becomes more complex to a centralized platform that can fill the gaps that automation alone won't.
The 27% with significant investments who've built custom platforms highlight both the recognized importance of release management and the substantial engineering resources diverted from product development to maintain these systems—resources that could be redirected to user-facing features. This cohort predominantly consists of larger organizations, showing how companies tend to paint themselves into a corner with custom solutions as they scale. It's the classic build vs. buy dilemma, but with a twist—even the "build" option isn't solving the fundamental problems.
Figure 10: Team's level of investment in automating the release process
Across our respondents, we saw a wide spread of both primary and secondary CI/CD tools in use, revealing a lack of consistency in current tool stacks. Mobile teams are living in a world of fragmented tools patched together with good intentions, but ultimately not meeting the needs of their release process. Â
The CI/CD providers most widely used as the main solution are GitHub Actions (32%) and Jenkins (24%). These are also the platforms that are most widely used even when they're not the primary solutions.
The wide distribution of providers creates a critical challenge for mobile teams, with each additional tool in the stack introducing new learning curves, maintenance requirements, and integration points, directly impacting developer experience and operational resilience. It's death by a thousand paper cuts—each individual tool might be fine, but the collective complexity is overwhelming.
This fragmentation highlights the need for an abstraction layer that can provide consistency in approach regardless of the underlying tools, allowing teams to focus on the release process itself rather than managing a complex toolchain.
Figure 9: Current use of CI/CD providers
Despite significant time, monetary, and tooling investment in mobile releases, most teams (51%) only view their processes as "somewhat" efficient.
This is surprising, given that over half of them (52%) also report spending about a third of each release cycle on non-productive or low-value tasks (as we saw in Figure 4)—a clear sign that inefficiency has been normalized to the point of invisibility. It's a bit like having a terrible commute for years—eventually, you stop noticing just how bad it is.
Only 11% report that their process is very efficient, 11% say it is somewhat inefficient, and 27% remain neutral.
This perception gap represents a critical challenge: teams have acclimated to release friction, making it harder to build internal advocacy for solving a problem many don't fully recognize—despite the quantifiable impact on DevEx and shipping velocity.
The 38% with neutral or negative efficiency ratings represent teams who've begun to recognize the issue, creating an opportunity for engineering leaders to lead organizational change by benchmarking their process against peers and quantifying the business impact of release friction.
Figure 8: Rating the efficiency of the current mobile release process
