The landing surface.
Where the scan arrives. Request a Song is elevated above every competing element, because the guest reading it is on their second drink, in low light, with no patience for a menu.
Prophilehouse · Founding team · 2024 — present
A real-time interaction layer for live music venues. One QR code on the table connects artist, venue and audience — song requests, acknowledgement, feedback — with no app install and no account. The design work was mostly subtraction: finding the single loop worth proving, and refusing to build anything else until it did.
The problem
We interviewed artists, venue operators and audiences. The same pattern kept surfacing: the richest moments of a live set are held in memory alone, and nothing in the room captures them. Every venue had a workaround. None had a system.
Shouting across the room, notes scribbled on napkins, waiters pressed into service as messengers. Whether a request reaches the artist depends entirely on the room.
People want to follow the artist they just heard. By the time they're outside, they've lost the name — and there was never a path from the table to the profile.
Applause and table conversation are the real reviews. Neither reaches the artist or the venue in any form they can act on.
Follower count is the only signal available when deciding who plays next weekend. Nothing measures what actually happened in the room.
Scoping the MVP
The obvious version of this product is a marketplace — artist discovery, booking, tipping, menus. We asked a narrower question instead: what is the one interaction that, if it works, makes everything else worth building?
One loop. Attributed to a table. Countable. If audiences don't request and artists don't respond, no amount of adjacent feature work saves the product — and we'd know within a handful of events rather than a year.
The core loop
The QR code on the table is the entry point and the attribution mechanism at once. It activates only during the live event window, so a scan is always tied to a specific table at a specific performance.
No app install, no account. The code is live only during the event window, and the session carries the table it came from.
The performing artist is the first screen — identity, context, and one dominant action.
Setlist as reference, custom input allowed, optional message. Two taps from landing to submitted.
Duplicates bucketed into demand, sorted by table. Built to be read at a glance, mid-set.
No confirmation dialog. The table is notified their request was picked up.
Prompted at session close. Rating plus optional comment, attributed to the performance.
The venue becomes a structured data layer while staying completely invisible to the night.
QR placement was tested for natural sightline from a seated position — the design work started at the table, not the screen.Who we designed for
The same event looks different from the stage, the office and the table — and the three want incompatible things from the same interface. Separating them into three surfaces was cheaper than compromising on one.
“I want to know what the crowd wants — without breaking my flow.”
“We need real data to book the right acts. Follower count isn't enough.”
“I just want to request a song without yelling across the room.”
Designing for live environments
A live set imposes hard constraints — split attention, high sensory load, and no tolerance for a second-guess. A dashboard that has to be read is a dashboard that won't be opened.
Signal clarity over feature density.
The principle every dashboard decision was checked against.What was built
Five surfaces, each answering to one role and one moment in the loop. Nothing here exists to be comprehensive; each piece earns its place by carrying a step the loop can't skip.
Where the scan arrives. Request a Song is elevated above every competing element, because the guest reading it is on their second drink, in low light, with no patience for a menu.
Setlist provided as reference with custom input allowed. The confirmation state gives closure so the guest doesn't check back — a small thing that removes a whole category of follow-up.
Requests bucketed by song, grouped by table. Toggles for accepting requests, enabling tips and managing the live session — all reachable without leaving the view.
Prompted at session close. Star rating plus an optional comment, tied to the performance rather than the venue — which is what makes it useful to both.
Request volume, engagement rate and satisfaction per session. The first objective input a venue can use to decide whether an act comes back.
The product
One screen carries the entire audience side of the loop — identity, request, setlist, gallery, upcoming shows and post-show feedback — in a single scroll, because a guest who has to navigate is a guest who leaves.
Early feedback showed the Request a Song action was being missed entirely in dim venue lighting — guests scanned, scrolled and left without using the one feature the MVP existed to test.
We rebuilt the screen around a single dominant action, cut competing elements out of the first viewport, and raised contrast until it held up in the room rather than on a desk. The loop only became measurable after that change.
Production screen from the live build.
What's next
The MVP validated the core loop. We're onboarding artists and refining against real event data, with each further layer gated on the one before it earning its place.
Reducing time from first sign-up to first live event, based on early-adopter feedback. Targeting 500+ artists.
Layered in only once request engagement holds. Designed to read as appreciation rather than a transaction.
Aggregated performance data across events — the booking signal that replaces follower count.
A discovery layer letting audiences keep the artists they found live. Unscoped; the loop has to hold first.
We're not replacing the emotion of a live performance. We're capturing the signal it creates — and making it actionable for everyone in the room.
Aditya Meshram · Founding team, product & systemsNineteen product areas of a derivatives platform, held together by one token system.