Snapshot
Role: Lead Product Designer / Design Engineer
Status: Live and being used in pubs, bars and friend groups
Built with: TanStack Start, React 19, TanStack Router, Vite 8, Nitro, TypeScript, Tailwind CSS v4, Radix/shadcn components, Neon Postgres, youtubei.js, YouTube Data API v3, YouTube IFrame API, GitHub Actions, Vercel
AI-assisted workflow: Lovable for the first visual prototype, Claude Code with Fable 5 for the working product, Neon MCP for database setup and SQL, Vercel CLI/API for deployment automation, ChatGPT + Illustrator for icon exploration
Research & validation: Real-life observation at a house barbecue and at Kataluma PUB in Natal, quick architecture research in Perplexity, QA by Fabio Paes, production testing through the pub team and browser/device checks, direct customer feedback from the venue owner, plus follow-up bar testing around YouTube embed failures
Timeline: A few hours across two days, from idea to live pub testing and final adjustments
Impact: Much lower workload for the host or hired karaoke operator, no need for singers to use the host's computer, faster queue flow with almost no pauses between songs, and an automatic blocked-channel filter after only 2 of 48 tested channels failed playback. A participation lift of up to 40% is an expected near-term outcome, not yet a confirmed metric.
Project link: karakuê
Problem
I have loved karaoke for years. The old machines with CDs and a score at the end eventually gave way to digital setups, and then YouTube made the music library feel almost infinite. For a small group, that works well enough: three friends can take turns, search for the next song on the same computer, grab the microphone, and keep going.
The first friction is the pause between songs. Someone has to walk to the laptop, search, choose the right video, press play, and hand the microphone over. With a few friends, that pause is annoying but acceptable. With a larger group, it becomes the thing that breaks the party.
At a recent barbecue with 14 people, two microphones, one laptop, and a projector, everyone wanted to sing. Every song change forced someone to go back to the computer. People who were not close to the host hesitated to ask for songs because they did not want to create work. Searching on the laptop took time, so people often settled for a random choice. The laptop owner also had to worry about guests, some of them drinking, repeatedly touching the computer.
The same pattern appeared at Kataluma PUB in Natal. On karaoke nights, some people would take over the laptop, creating friction for anyone else who wanted to sing. The owner had to stay near the laptop to manage the queue, prevent microphone monopolies, and protect the equipment. In small venues, the cost of running karaoke can become high enough that some bars hire someone just to organize the queue.
Bet
The initial bet was simple: if guests can request songs from their own phones, and if the host can manage the queue remotely without exposing the laptop, karaoke nights can keep moving with less friction and less operational cost for the host. As the flow gets faster and easier to join, participation should increase too, but that still needs more measured usage data.
For the pub owner, that meant more time to run the bar instead of standing beside the laptop. For house parties, it meant anyone could participate without having to interrupt the host or touch the main device.
Build
Karakuê is a browser-based collaborative karaoke queue. The host creates a room in seconds, names it, chooses a queue mode, and shows a QR code on the TV or projector. Guests scan the code, enter with only a nickname, search the full YouTube catalog, and add songs to the queue without creating an account or installing an app.
The room creation screen keeps setup fast: name the room, choose the queue mode, and open the shared karaoke queue.
The video plays through the official YouTube player on the main screen. When a song ends, the queue advances automatically. Everyone can see what is playing now, what is coming next, and who wants to sing along.
The queue can run in three modes:
- Rotation: the default mode, interleaving one song per person so nobody monopolizes the microphone. If only one person is singing, their songs continue until more people join.
- Free: first come, first served.
- Democratic: guests vote, and the most requested songs move up.
The guest journey is intentionally short: scan the QR code, enter a name, find a song, and wait in the shared queue.
The host has a control panel for the realities of a bar or party. They can add songs on behalf of someone who does not want to scan a QR code, reorder the queue with drag and drop, skip or go back, play any song immediately, lock new requests, and clear the queue. On a computer or projected on a TV, the panel runs full screen with the video on one side and the room/queue controls on the other.
The host view keeps the YouTube player, QR code, room code, manual request form, and queue controls visible while the laptop stays isolated from the crowd.
The product was built through a fast AI-assisted workflow. I had the idea after visiting the pub, did a quick 10-minute architecture and technology search in Perplexity, created the first interface in Lovable in about 20 minutes, moved it to GitHub, and used Claude Code with Fable 5 to make it work as a real product. The first version was tested the same day, QA feedback came back quickly, and the pub team tested it that night. The final adjustments took about another hour in Claude, plus roughly 20 minutes using ChatGPT and Illustrator for the icon.
The final architecture keeps the product small: no dedicated backend, server functions running on Vercel, Neon Postgres as the source of truth, and YouTube as the music catalog. The live search uses a lightweight YouTube search integration that works without requiring users to configure an API key. That search flow is deliberately separate from a reliability check: a small automated script uses the official YouTube API only to verify whether selected videos can be embedded. It checks videos in batches, keeping the verification inexpensive.
GitHub Actions runs that script on a weekly schedule and also supports manual runs, producing the blocked-channel report without a dedicated server or a reminder to run it by hand. The player remains the runtime safety net: if a video still fails because its channel blocks playback in external apps, Karakuê detects the error, adds the channel to the internal blacklist, and filters that source from future searches.
Validation
1. First feedback: the host needs to add songs too
The first QA pass surfaced a missing host workflow. In the first version, only guests could add songs after scanning the QR code or opening the shared link. The host could show the room, video, and queue, but if no guest had added a song yet, the host had to open another tab and join as a guest.
That changed the product. The host can now add requests directly, including on behalf of people who prefer to shout a song name instead of scanning. This also made the room more flexible for venues: the owner can seed the queue with popular songs, suggest that people get up and sing, and rebalance the queue when one group starts to dominate the microphone.
2. Pub feedback: not every search should force karaoke
The pub test surfaced another real-world behavior: not everyone wants a pure karaoke track. Some people prefer the full song with vocals. Karakuê originally added the word "karaoke" to YouTube searches automatically so guests did not have to type it. After the pub feedback, I added a toggle so the user can remove "karaoke" from the search and find full versions too.
3. Fairness feedback: host-added songs need singer names
The pub also showed that treating the host as a single user could break rotation fairness. If the owner added several songs for different people, the system would still treat all of them as the host's songs. The fix was to let the host add each request under the name of the person who asked for it, preserving the rotation logic.
4. Reliability feedback: some YouTube videos fail in embeds
A later round of bar testing surfaced a different kind of failure. Some songs appeared in search but would not play inside Karakuê, forcing the venue to open YouTube directly and break the flow. Looking at the error messages showed that some YouTube channels block playback in external applications, likely to keep viewers on YouTube itself.
The fix was to treat the failure as a learning signal. The weekly API check can identify channels whose videos are not embeddable before they create friction, while the player catches any restriction that appears during a real session. In both cases, the channel is added to the app blacklist and filtered out of future searches. In the first validation round for this issue, only 2 of 48 tested channels were blocked.
Impact
Karakuê is live at karakue.brunix.studio and is being used by bars and groups of friends.
The feature set stayed small and practical: low-friction entry, fair queue behavior, remote host control, and automatic filtering for channels that block embedded playback.
1. Lower host workload
The immediate impact is operational. The workload drops for whoever controls karaoke, whether that is the host or someone hired by the venue. Singers no longer need to use the host's computer, the notebook stays isolated, and the host can control the room remotely instead of standing next to the laptop.
2. Faster karaoke flow
The queue moves faster because guests choose songs while the current video is still playing. The flow has almost no pauses between songs, and the owner can keep working instead of returning to the laptop after every performance.
3. Direct customer signal
That operational change showed up clearly in the venue feedback:
"Muito massa a experiencia com o Karakuê, porque antes nao era automatico, eu ficava muito presa a dar atençao e tudo mais e eu tenho varias outras coisas pra fazer aqui durante a noite, e todo mundo gostou, todo mundo usando o QR code, acho que a galera vai voltar porque virou um diferencial! Obrigada de verdade."
Literal translation: "The experience with Karakuê was really cool, because before it was not automatic. I was very stuck having to pay attention to everything, and I have several other things to do here during the night. Everyone liked it, everyone was using the QR code, and I think people will come back because it became a differentiator. Thank you so much."
— Maria Antonieta, partner at Kataluma PUB, Natal, Brazil
For the case, the important signal is not only that people liked the interface. The owner described the exact behavior Karakuê was designed to change: before the product, she felt stuck managing the karaoke flow; after introducing the QR-code queue, guests could participate directly while she kept running the bar. She also framed the experience as a venue differentiator strong enough to make people want to return.
4. Participation hypothesis
Based on this reduction in friction, I expect participation to increase by up to 40% in the near future, but that is still a hypothesis to validate with more usage data, not a confirmed result today.
5. More reliable search results
The blocked-channel filter also improved the product's reliability model. The app does not need to solve every YouTube restriction upfront: a low-quota official API check runs weekly, GitHub Actions handles the routine work, and the player learns from real playback failures. Together, they remove unreliable sources from future results and make the error less likely over time without adding a dedicated server.
6. Better social dynamics
The product also changes the social dynamic. People who would otherwise avoid asking for a song because they do not want to bother the host now have a low-friction way to join. The microphone is less likely to be monopolized because the queue modes encode fairness directly into the product.
What I learned
1. AI can compress the path from idea to live test
Karakuê was the first project where I could really put Fable 5 into a live product workflow. It made the build dramatically faster than the AI tools I had used before, although that also creates a risk: because the model and workflow are so new, parts of the process may feel dated quickly.
2. Real behavior beats abstract queue design
There were no major product trade-offs because the scope was intentionally simple and the timeline was extremely short. The most important decision was staying close to the real karaoke night instead of designing an abstract queue product.
The host workflow, the "include karaoke in search" toggle, and the ability to add songs under different names all came from observing how people actually behave in a party or pub.
3. Third-party catalogs need graceful degradation
The YouTube embed restriction became a useful reminder that a product built on top of a third-party catalog needs graceful degradation. Some karaoke channels restrict playback so videos can only be watched directly on YouTube. The important product move was not to pretend this edge case would never happen, but to make the app learn from it and gradually hide sources that break the karaoke flow.
