The Data-First Approach to Mobile DevOps at Spotify

Infrastructure and tooling have always been critical to how Spotify engineers build and ship products. The challenge is making sure those systems don't get in the way of feature development. Over the past few years, Spotify's mobile DevOps teams have leaned heavily on a "data first" mindset to guide their decisions — not just on backend systems, but also for the mobile developer experience.

Where Agile and DevOps Meet (and Diverge)

Agile methodologies offer a lot of value, from adaptive planning to continuous delivery. But they leave certain operational gaps open. Historically, teams were left to manage their own system administration, which can eat into the time spent on product quality.

DevOps helps bridge that split between developers and IT infrastructure. By closing the loop between writing code and running it, teams can automate repetitive tasks, maintain healthier systems, and let developers spend their energy on the actual product.

Why Mobile DevOps Is a Different Beast

Mobile development introduces a different set of constraints compared to backend work. With large, monolithic codebases being modularized, and release cycles that stretch longer than microservices updates, mobile teams face unique risks. New app versions roll out in phases—alpha, then beta—and each phase needs active monitoring for any bugs that could hurt the user experience.

Mobile DevOps teams generally operate with two goals: improving app quality and increasing developer productivity. The two are closely connected; better tooling gives developers more time to focus on what ends up in the hands of users. The aim is to prepare for problems before they actually surface, whether that means build time regressions, unfamiliar bugs, or degraded performance.

The Push for Data Literacy at Spotify

Spotify’s renewed focus on data began around 2017. The objective was to embed data into business decisions across the company. That meant the data infrastructure teams needed to make it easy to generate, collect, and analyze data. Alongside that, the Tech Learning team introduced Data University, a training program to help engineers use data to solve product problems. Over four years, more than 500 employees—including engineering managers and product managers—have gone through the program.

The internal education paid off. When engineers returned to their squads, many started applying that mindset to their own infrastructure. One early use came from the Android infrastructure team, which was dealing with slower build times and a local development experience that felt clunky.

They looked for ways to automate the collection of baseline metrics, trace historical data, and understand system behavior more deeply. Reducing the number of build system components was also a goal, but that required better visibility into a single piece of the process. The key insight: you can’t manage build time properly unless you have infrastructure that can actually measure and analyze it.

Ownership and Tooling Across Platforms

At Spotify, data infrastructure is handled by dedicated tribes, which provide building blocks for collecting data and visualizing it. But the data generation side depends on each platform and its specific tooling.

For Android, Gradle Enterprise already provides a smooth path for generating and storing build data. The focus was on the data pipelines and the dashboards. iOS was different — no established solution existed for that kind of tracking, so Spotify built its own internal tools.

The mobile DevOps teams had to build a lot of this support themselves. Once the data pipelines were established, they added dashboards and data checks to ensure that as the volume and complexity grew, the quality would not degrade. Over time, maintaining and improving the data layer became a regular prioritized task. Owning that data culture paid off: product teams started using the visualizations to validate decisions and drive conversations, rather than guessing.

Observability With Accountability

Building dashboards is one thing; getting people to use them regularly is another. Early on, the teams found that glancing at a dashboard sporadically wasn't effective. The solution came with a combination of process and ownership:

  • Alerts were added to flag regressions and broken pipelines, enabling quicker response times.
  • Owners were assigned to each dashboard, responsible for keeping them current and accurate.
  • These dashboards matured into standard fixtures in internal meetings with stakeholders who wanted to track productivity metrics for their components.

Eventually, the dashboards were made available across the organization, giving feature developers direct access to the data and the ability to keep an eye on their own metrics.

Planning With Historical Data: A Concrete Example

With good data in place, planning becomes much sharper. Consider a request to “deliver a frictionless experience for Swift development at Spotify.” "Friction" can mean different things in eng — from slow incremental builds to confusing error messages or flaky tests.

Dashboards can show build trends by language across iOS components. If Swift's component count is on track to surpass Objective-C, that becomes a clear signal to prioritize Swift build performance. Being able to predict when a system will become inefficient means the team can act before engineers feel the pain.

That practice extends beyond build times. Data helps with migration planning, answering questions like which environments or APIs are actually being used by developers, how many components a typical pull request touches, and whether remote caching is turned on. Those specific details matter when trying to validate the impact of any change. It is common to separate decisions into two groups: those we have enough data to tackle now, and those that need additional data collection first.

The cycle feeds into planning, implementation, and evaluation:

  • Planning rests on historical baselines, setting an expectation to maintain or improve numbers as the codebase grows.
  • New tasks can be written to capture missing data points during the next round.
  • Evaluation benefits from a fast feedback loop. The data usually reflects the impact of a change within a day, allowing for quick course correction.

Product managers use the data as more than just a measurement tool. Instead of constantly relying on early-stage user research — which has its blind spots during the conceptual phase — the dashboards provide a way to evaluate solution effectiveness, adoption trends, and satisfaction more directly.

The Ongoing Data Journey

For Spotify's mobile DevOps teams, treating data as a first-class tool hasn't just changed how infrastructure gets built; it has changed how prioritization happens. Problems can be addressed before they ever reach developers, often before anyone has noticed them. The data-led culture, seeded by internal education and carried through by team ownership, has produced consistent improvements. There remain areas to explore, particularly how data can guide broader architectural changes, but the path forward is clear: data continues to lead the way.