Solution
Audio streaming apps
Music, podcast and radio apps — including the car, where audio is the main event.
- Listens on
- Phone
- Web
- Smart TV
- Speaker
- Car
- Shared across all of them
- Catalogue
- Sign-in
- Queue
- Playback engine
- Built per product
- Music
- Podcast
- Radio
Where people actually listen
At home and in hand
One catalogue, one sign-in, one queue and one playback engine, across the phone, the web, the television and the speaker. Playback that keeps going when the screen goes off is architecture rather than a setting — it is the part that separates an audio app people keep from one they uninstall.
And in the car
The most constrained place your app will ever run, and the one where audio is the main event rather than a version of something else with the picture removed. CarPlay and Android Auto impose how your catalogue can be presented, and that reaches back into how it is structured. It is why we scope the car first rather than last.
What you get
- A music, podcast or radio app on phones, web, smart TVs and speakers
- CarPlay and Android Auto, scoped from the start rather than bolted on
- Playback that survives the screen going off, a phone call and the handover to a car
- A catalogue model built for artists, shows and episodes rather than for titles
- Offline listening with expiry and territory rules enforced on the device
Typical timeline
2 to 5 months, depending on how many platforms are in scope
Who this is for
Audio services, and the people inside video companies who have an audio product nobody has built properly for yet.
The three share a foundation and differ enough that treating them as one job goes wrong. A music catalogue is artists and albums. A podcast catalogue is shows and episodes with a running order. A radio product is mostly one continuous stream with metadata attached to it. The playback engine is shared. The catalogue model is not.
Most OTT studios treat audio as video with the picture removed. It is a different product, and the place that shows most clearly is the car. If you are looking for a music streaming app development company rather than a video studio that will also take audio work, that distinction is the point of this page.
Music streaming app development
Starts with artists and albums, and a queue that is most of the product rather than a convenience.
Podcast app development
Starts with shows, episodes and a running order, where resume position matters more than discovery does.
Radio streaming app development
Starts with one continuous stream and metadata attached to it, which is a different problem from a catalogue of things to pick between.
White label music streaming app
Starts with a brand and a licensing deal already in place, and needs the app under your name rather than ours.
What we deliver
An audio service on the screens people actually listen on: the phone, the web, smart TVs and speakers, and CarPlay and Android Auto.
The in-car part is the one worth taking seriously. A music app for Android Auto and a podcast app for CarPlay are not scaled-down phone apps — the car imposes how your content can be presented, and that constraint reaches back into how your catalogue is structured. Building for it early is much cheaper than retrofitting it, and it is the single most common thing we see left until last.
If your service is video and audio is the second product, the video side of this is the companion page.
How the build runs
We start with the catalogue model, because it is the decision everything else inherits. Getting artists, shows, episodes and chapters right early is what stops the car build turning into a rewrite.
Then playback, which for audio means playback that keeps going when the screen goes off, survives a phone call, resumes where it stopped and hands over cleanly between a phone and a car. That is architecture rather than a setting, and it is the part that separates an audio app people keep from one they uninstall.
Settle the catalogue model
Artists, shows, episodes, chapters. Everything else inherits this decision, and changing it later is expensive.
Build playback properly
It has to keep going when the screen goes off, survive a phone call and resume where it stopped.
Take the car early
The car constrains how content can be presented, and that reaches back into the catalogue. Late is what makes it costly.
Add offline and the queue
Downloads bring storage, expiry and territory rules. For a commuting audience this is not optional.
Submit per store
Each platform reviews differently, and the car platforms have their own review on top.
What actually varies
We do not publish a price. Here is the more useful thing: what moves it.
| Driver | What it changes |
|---|---|
| Music, podcast or radio | They share a player and differ in catalogue shape, rights handling and how much of the product is a queue. Building two of the three at once is common and is not free. |
| Whether the car is in scope | It should be, and it is real work. Deciding late is what makes it expensive. |
| Offline listening | Downloads mean storage, expiry and licence enforcement on the device. For a commute-heavy audience it is not optional. |
| Catalogue size and metadata quality | A small, clean catalogue is a different job from a large one assembled from several sources with inconsistent metadata. |
One limit worth saying plainly, because it should change what you ask us for.
We build the app, not the licensing. Deals with labels, publishers and collecting societies are yours to hold, and reporting obligations usually come with them. We will tell you where your licence terms constrain what the app can do — offline windows, territory limits, skip rules — but the app does not come with the rights to play anything.
What we need from you
- Which of music, podcast or radio you are building, and whether the others are coming later. It changes the catalogue model, which is expensive to change afterwards.
- Your catalogue and its metadata, or an honest description of its state.
- Your licence terms, specifically anything about offline listening, territories and skipping.
- Whether the car is in scope now or later, answered honestly rather than optimistically.
You will be talking to the people doing the work, which matters here because most of the early decisions are about the catalogue rather than about the app.
Common questions
Do you build audio apps, or only video streaming apps?
Both. Music, podcast and radio apps are as much in scope as video, and in the car they are the main event rather than a reduced version of something else. If you are an audio-first service, you are not an awkward fit here.
How is an audio app different from a video app?
Playback has to survive the screen going off, which changes the architecture rather than adding a setting. The catalogue is shaped around artists, albums, shows and episodes instead of titles. And listening is continuous, so the queue is a core part of the product rather than a convenience.
Can you build for CarPlay and Android Auto?
Yes, and it is worth building for early rather than last. The car is the most constrained place your app will run, and designing for it afterwards usually means reworking the catalogue structure to fit.
Do you handle music licensing?
No. Rights deals with labels, publishers and collecting societies are yours to hold, and we would not pretend otherwise. We build the app that plays what you have licensed, and we will tell you where your licence terms affect what the app can do.
Related
Last updated