The Fragmented Car: Why Building for the Dashboard Is Hard

Drivers are a massive audience for Spotify, so making sure the in-car experience is both safe and functional matters. That goal runs into three structural obstacles: the variety of ways Spotify can be used in a car, the range of screens and input methods cars ship with, and the simple fact that the driver’s primary attention belongs on the road.

There are three distinct ways to get Spotify into a vehicle:

  • Bluetooth: The car’s speakers act as audio output. Users get basic transport controls—play/pause, skip forward, skip backward—via the head unit and steering wheel buttons.
  • Projected experiences: Apple CarPlay and Android Auto mirror phone apps onto the car’s media display. These give access to richer features like playlist browsing, search, and a dedicated Now Playing view.
  • Embedded apps: An increasing number of manufacturers, including Tesla and Android Automotive cars, run standalone native apps on the vehicle’s own operating system, with access to in-car hardware and a dedicated media interface.

Most vehicles support Bluetooth, and many also offer projected or embedded options. A single car can therefore present Spotify users with multiple simultaneous surfaces. Add in smart speakers, TVs, watches, and other devices running the app concurrently, and the requirement for seamless cross-platform operation becomes clear.

Screen sizes range from tiny displays that can hardly show a track name to tablet-class panels. Input methods are equally varied: physical buttons, rotary dials, touchscreens, steering wheel controls, and voice. Car manufacturers actively differentiate their offerings, which compounds fragmentation and raises the integration burden for developers.

Safety reshapes the design constraints in ways other surfaces don't face. Selecting audio is a secondary task in the car, so the experience must minimize cognitive load and avoid anything—unexpected interruptions, confusion about what's playing—that could pull the driver’s eyes or mind off the road.

Decision-Making for a Fragmented Domain

Spotify’s distributed teams rely on Slack for day-to-day communication, but threaded chat isn't well suited to deep technical discussion. For decisions, the company prefers Request for Comments (RFC) documents. An RFC focuses on a single problem, lets stakeholders weigh in asynchronously, and iterates on a proposed solution. The standard structure works like this: state the problem, give context, then lay out a proposed solution alongside alternatives. Once ready, the doc is shared with stakeholders for feedback.

Several practices make RFCs effective in the automotive context.

Break Large Problems into Smaller RFCs

Technical problems vary in size. Small ones fit neatly into a single RFC, but large ones produce documents too long to digest. Spotify’s approach has been to split those big issues into pieces: first, publish a big-picture RFC that lays out the problem and high-level solution space for all stakeholders, and once that route is decided, produce smaller, focused RFCs that drill into specific sub-problems and reach only the relevant teams.

Automatic playback on car connection is the example. When a car connects, Spotify is expected to resume based on the user's listening history. The bird’s-eye RFC covered the high-level architecture—whether to build a new system or extend an existing one, what the API should look like, and what content gets played. Once that direction was locked, detailed RFCs addressed detecting the car connection signal, defining when auto-play should not trigger, experimenting with content types for the best experience, and filtering content for in-car listening. Audiences were tailored per topic: content RFCs went to content teams, connection-signal RFCs to the teams owning connected accessories.

Diagrams and Code Move the Discussion Forward

Explaining major system changes clearly demands more than prose. Spotify RFCs routinely include diagrams, code snippets, and even draft pull requests. Architecture diagrams show connections and dependencies; user-journey diagrams expose shortcomings in the current flow. Code examples standardize implementations of protocols or features, which is especially useful when proposing changes to another team’s system—consistent examples keep everyone aligned.

For instance, an RFC about automatic playback failures went to external teams that owned dependent systems. User-journey diagrams illustrated the problem areas at a glance, and code examples made the suggested improvements concrete and understandable.

RFCs for Collaborative Problem-Solving

Once, a tricky in-car playback issue surfaced. It was initially reported as a bug but was hard to reproduce in the standard test setup, and deeper investigation suggested it spanned multiple teams with wider impact than first thought. Spotify compiled everything known into an RFC, describing the team’s part of the system and leaving blank sections for other affected teams to fill in. That structure let everyone verify the collective findings, made buy-in easier, and forced consideration of all perspectives before fixes were prioritized. Rather than patching the issue locally, the group evaluated impact and sorted options first.

Aligning Product, Engineering, and Data Science

An RFC’s structure—problem statement, rationale for fixing it, and solution ideas—naturally brings together people from different functional groups. Spotify used this to plan new logging for a feature, with Product defining the requirements and Engineers and Product Insights determining how to implement it. The same pattern applies to supporting features like AI DJ and Jam in cars, where cross-functional questions arise:

  • Does the current architecture support the new feature, or does it need enhancement?
  • Does the car integration need more data than the core API currently exposes?
  • How will logging determine that listening is happening in a car?

RFCs provided the common forum for engineers, product managers, and data scientists across verticals to converge on these decisions without boiling over into disorganized, disjointed discussions.

Making the Call on Architecture: How Spotify Uses RFCs for In-Car Integration

The road to putting Spotify in the car is a study in handling complexity. The automotive landscape is highly fragmented—different manufacturers, different hardware capabilities, different operating systems—and that fragmentation demands a decision-making process that can keep up. For Spotify’s engineering teams, the answer has been a disciplined use of Request for Comments (RFCs) to structure collaboration and technical direction.

RFCs at Spotify are not the formal, standards-body artifacts the name might suggest. They are a pragmatic tool: a written proposal that lets engineers lay out a technical problem, sketch a solution, and invite critique before committing to implementation. The goal is to make sure that when a significant architectural decision is made, it has been examined from multiple angles and has the buy-in of the people who will build and maintain the system.

Why RFCs Fit the Automotive Problem

The in-car project is not a single integration; it is a matrix of them. Spotify must work across a range of device classes—from embedded head units to Android Auto and Apple CarPlay—each with different constraints and feature sets. A decision that works for one platform may break the user experience on another.

In this kind of environment, spontaneous, chat-based decisions can lead to inconsistency and rework. RFCs provide a counterweight. By pushing discussion into a written, asynchronous format, they create:

  • A record of intent: A document that explains why a particular approach was chosen, which proves useful months later when someone asks why the system behaves a certain way.
  • A wider review network: Not just the immediate team, but the broader group of engineers across other platform squads can look at change early in the process.
  • A structured space for conflict: Disagreement is a normal part of engineering, but it can be hard to work through in a meeting. An RFC gives it a legible, shared frame.
The problem comes when the team’s internal, conversational preferences leak into the formal proposal, making the RFC less a design document and more a transcription of what already happened in Slack.

Ask the reviewer to point out where they disagree and where they see holes, and rely less on a verdict from anyone. Disagreement in review is a signal that the proposal is meeting scrutiny, which is better than a quick green light.