This is a submission for the GitHub Finish-Up-A-Thon Challenge
What I Built
VKara is a browser-based karaoke room app for singing at ho...
For further actions, you may consider blocking this person and/or reporting abuse
This is a strong finish-up story because the “comeback” was not just adding features. It
was making the project safe to change.
The TV/phone role split is the key product insight here.
At first glance, karaoke sounds like a video problem. But the real problem is room
coordination: who can add songs, what is next, who controls playback, what happens when
someone reconnects, and how the queue stays understandable while people are actually
singing.
That is why the monorepo/shared-contract work matters. For a realtime room app, frontend/
backend agreement is the product. If the WebSocket event shape drifts, the UX breaks
immediately.
I also like that you avoided the obvious “add AI lyrics” kind of roadmap thinking. The
most valuable next features are probably still human-room features: turn order, queue
limits, host permissions, rejoin recovery, and maybe saved room history.
“TV as screen, phone as remote” is simple enough that users can understand it instantly.
That is usually the sign that the product finally found its shape.
Thank you, this really gets what I was trying to do 😆😆
“Making the project safe to change” is a great way to describe it. That was the biggest difference between the old version and this rebuild.
And yes, I agree. The next useful features are probably still room/queue/permission improvements, not flashy roadmap stuff.
Exactly. That “safe to change” phase is easy to underestimate because it does not look
like a feature from the outside.
But for a realtime room app, it is probably the difference between “cool prototype” and
“I can actually trust this during a karaoke night.”
The queue/permission layer feels like the right next step because that is where the
product becomes social instead of just functional:
Those are small rules, but they define whether the room feels calm or chaotic.
The strong thing about VKara is that the core idea is already simple: TV plays, phones
control. So the next features should protect that simplicity, not add noise on top of it.
Really nice rebuild.
Lovely to see how you used copilot to think through how to solve the problem, rather than have it code out the solution. This is the proper way of having AI, and I have learnt a lot from your experience ideating through the product and building it out while solving problems along the way.
Thank you! I really appreciate that.
That was the biggest lesson for me too. AI helped more when I used it to reason through the problem, not just generate code.
it's cool how you addressed the need for a collaborative karaoke experience with vkara. making everyone's phone a remote adds a fun twist. if you're interested in another project, moonshift lets you get a full next.js + postgres + auth app deployed in about 7 minutes, and you own the code on your github. happy to help you get a free run if you want to try it out.
Thanks! The phone-as-remote flow is the main thing I wanted to get right.
Moonshift sounds interesting - feel free to drop a link. I’m focused on VKara for now, but I’ll check it out.
Small update after publishing this 😄
I kept working on VKara for a few more days. The changes were mostly polish around the real karaoke flow: phone remote UX, TV/player layout, search, queue actions, playback sync, reconnect/recovery, and YouTube handling.
I also merged a larger monorepo refactor. The old shared-* packages were turning into catch-all folders, so I split the code closer to the actual product areas instead.
For that PR, I used GitHub Copilot PR Review as an extra verify step. It was useful for a large structural change, but not a replacement for my own review.
PR here if anyone’s curious:
github.com/lehuygiang28/vkara/pull/2
Thanks for reading 😄
If you try the demo, use two devices. Open the room on a laptop/TV, then join from your phone. That is the main flow I built this app for.
Feedback is welcome, especially if the queue or room controls feel confusing.
This is a really cool idea.
I like that you’re not trying to replace YouTube, but instead building around the awkward part of karaoke nights: letting everyone search, queue, and control songs without passing one remote around.
The TV/phone role split makes a lot of sense too. TV as the clean playback screen, phone as the remote, is a much better mental model than just making a responsive video app.
Also really liked the point about making the project “safe to change” before adding more features. Moving the frontend/backend into a monorepo and sharing WebSocket/API contracts sounds like one of those boring changes that probably makes every future feature less painful.
The “Think → Ask → Plan → Execute → Verify → Repeat” workflow is a great takeaway as well. Feels like a much healthier way to use AI than just asking it to generate code and hoping for the best.
Nice work. This feels like one of those simple ideas that only seems simple after someone has done all the hard realtime/product thinking underneath it.
Thank you 🤩
That “boring changes that make every future feature less painful” line is exactly how this rebuild felt.
The old version had the idea, but it was hard to trust. After cleaning up the structure and contracts, adding features feels a lot less scary.
And yes, using AI to understand, plan, and verify helped me much more than just asking it to generate code.
Really appreciate the thoughtful comment!
Great explanation of how you went about the "revival" of your project - the thinking behind it, setting clear goals, the "new' approach to using CoPilot, etc - well written, I enjoyed reading this!
P.S. never heard of Elysia - looks pretty cool ...
Thank you! Glad you enjoyed it 😄
And yeah, Elysia has been nice so far - lightweight, TypeScript-friendly, and a good fit with Bun.
This is great!
Thank you! Glad you liked it 😄