Building a specialized music streaming service

How we built a music streaming platform that aligns with the values and music preferences of specific communities and uses both specialized client devices and mobile apps.
Background screening hero image

Mainstream music listeners have a lot of options when it comes to choosing services which will play the music they like. Spotify, iTunes, Apple Music, YouTube Music, Deezer - to name a few - are all serving the similar purpose when it comes to streaming music and other content, such as podcasts.


If you - either as a listener or a musician - have a particular preferences and do not prefer mainstream genres, or if the above mentioned platforms do not align with your values and your taste, it is almost impossible to find an appropriate online solution.

Our client wanted to create a platform to support a different type of content, which can’t be found using the conventional music apps and online outlets. One of the main reasons for this enterprenurial endeavor was that the general content on all of the other music apps was not aligned with the values they wanted to represent and share between the members of their community. Besides that, the volume of the content was not enough to be financially significant, which is why none of the mainstream music platforms didn’t show much interest in accomodating their needs.


The platform we built needed to fulfill its potential to change the music industry of client's community and to give listeners better control over the content while allowing content producers to geenrate better revenue.

Besides that, it needed to be fresh, modern and it needed to keep the pace with the established music apps such as Spotify and iTunes by including majority of their most popular features. The platform needed to be connected to a physical "radio-like" device, where the actual music would be listened on, but it also needed to be compatible with the mobile app which we designed and implemented.

Transforming the audio experience mobile application


We have implemented a Single Page Application (SPA) that was able to support both end-users as well as administrators. Administrators are using the system to manage all content, while users are setting their preferences and interact with the content.

Besides that, we introduced a feature that randomizes the content which is to be played next, making the whole experience more enjoyable for the user - the system chooses the content for the users, rather than having them to scroll through the list looking for it.

Payment processing system was created which enables users to access the premium content, and supports complex reimbursment calculations for content creators.

Finally, in order to keep track of users’ behavior, an extensive analytics module was added.

Technical details

Client-side functionality

React framework is the de facto standard for building SPAs, so it was our obvious choice - it is fast, reliable, and powerful in manipulating complex user interfaces. As a state management tool, we decided to go with MobX ( Our first step was to build core services. Our SPA architecture is based on practices described in the MobX documentation:

Business logic is divided into multiple data and UI stores that are interconnected. UI stores are even more specific; since their main purpose is to manage the state of each React component, each React component has its UI store that is created on a component mount lifecycle event and injected as a prop value.


Our server is a REST API service built on a .NET Web API framework and composed of two logical modules - core and analytics.


It is responsible for handling user authentication, content management, and payment processing. Server interacts with our primary data store (PostgreSQL).


One of the main requirements was to keep record of what is currently playing on each device. This introduced a challenge related to storing and processing high volume of data and generating complex reports based on it in reasonable amount of time. Classic RDMBSes like PostgreSQL, which we had already used, didn't match our needs.

Our first choice was TimescaleDB because it is based on PostgreSQL and is suited for storing time-series data. We did reduce storage size, but we didn't benefit much in query speed compared to the standard PostgreSQL database. Under the hood, it is still a PostgreSQL database that relies on its algorithms during query processing.

Fortunately, ClickHouse managed to fulfill all our expectations. Data compression works great, and SQL queries are multiple times faster compared to the standard PostgreSQL or TimescaleDB. There is also an option to connect to external PostgreSQL databases which we find very useful.

Our tech stack
Microsoft .NET

Book a free consultation

Let us know what would you like to do. We will probably have some ideas on how to do it.