Context: Application
The problem: requests compete with the set
Requests arrive as shouted conversations over the monitors or scraps of paper on the mixer. RequestLine brings them into one visible queue, with a route for the audience to participate while the set is running.
The approach: one visible route for requests
A fan scans a QR code and sends a request through Telegram. Votes determine the queue order, duplicate requests collapse into one, and the live board behind the booth lets the room follow what is moving up.
The result: a queue and a record of the set
Tracks that actually get played assemble into a Spotify playlist that followers can pick up afterwards. The dashboard brings together submitted requests, people in the room and voting activity.
Technologies and skills
- Product thinking: the request flow starts with the practical conditions of a DJ booth and its audience.
- Integration: QR entry, Telegram requests, a voting queue, the public board and Spotify connect different parts of the experience.
- Automation: duplicate requests are consolidated and the played set becomes a playlist.
What this demonstrates—and what it does not
The project connects several parts of a real workflow: audience entry, requests, voting, the booth display and a playlist afterwards. The design question is how to make that path understandable while the DJ is working.
This case study describes the implemented workflow. It does not provide measured audience adoption, uptime or a controlled comparison of interruptions before and after. Those would require separate evidence.