Snapshot
Role: Lead Product Designer / AI-assisted Design Engineer
Status: Live and being used in 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 IFrame API, 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 Katalima Cafe Pub in Natal, quick architecture research in Perplexity, QA by Fabio Paes, production testing through the pub team and browser/device checks
Timeline: A few hours across two days, from idea to live pub testing and final adjustments
Impact: Reported 40% increase in bar participation, less dead time between songs, safer laptop setup, and less operational burden for the venue owner
Project link: https://karakue.brunix.studio/
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 Katalima Cafe 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 organizer can manage the queue remotely without exposing the laptop, karaoke nights can keep moving with less friction, more participation, and less operational cost for the host.
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 organizer 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 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, how many votes each song has, 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 organizer 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 TV, the panel runs full screen with the video on one side and the room/queue controls on the other.
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.
Validation
The first QA pass surfaced a missing organizer workflow. In the first version, only guests could add songs after scanning the QR code or opening the shared link. The organizer could show the room, video, and queue, but if no guest had added a song yet, the organizer had to open another tab and join as a guest.
That changed the product. The organizer 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.
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.
The pub also showed that treating the organizer 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 organizer's songs. The fix was to let the organizer add each request under the name of the person who asked for it, preserving the rotation logic.
Impact
Karakuê is live at karakue.brunix.studio and is being used by bars and groups of friends.
The immediate impact is operational. The pause between songs is reduced because selection happens while the current song is still playing. Guests can request from their own phones, the notebook stays isolated, and the organizer can control the room remotely instead of standing next to the laptop.
At the bar, participation reportedly increased by 40%. The owner can keep working and only return to the karaoke flow when the list stops or when she wants to add a song herself and encourage people to sing.
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
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.
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 organizer 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.
The current technical limit is YouTube embed availability. Some karaoke channels restrict playback so videos can only be watched directly on YouTube. If that becomes a major issue in real use, the next product decision will be how to handle unavailable videos without breaking the flow.
