Swara Lounge: A Lightweight Video Room for Remote Music Jams

Swara Lounge started with a pretty simple thought: let me try building a lightweight Zoom-like meeting product end to end. Around the same time, some of my music and creative work had me collaborating remotely with singers, instrumentalists and audio people.

People working remotely on music already tend to record their own parts or stems. What struck me was what happens when everyone gets on a call afterwards — one person plays or shares something, stops, somebody else takes over, and so on. I started wondering: why couldn't those individual parts come into the room itself and be experienced together?

That question took me into territory I hadn't worked with as much before — WebRTC, browser media, multiple streams, synchronization and device behaviour. Somewhere along the way, my little Zoom-like build started turning into Swara Lounge.

The demo

Here is the build in action. It starts off looking like a regular video call. Then four people bring in their own recorded parts, take turns playing them, and finally switch into Jam Mode — four machines, four places, trying to play one piece together.

A small side story: I built much of this demo programmatically too — from staging the four participants and measuring the audio and timing to fitting the narration and assembling the final video. Coding agents helped me build the tooling; I still made the creative and judgment calls.

From a video room to Jam Mode

The product kind of grew one layer at a time.

• First, just get the video room working.
  People join, see and hear each other, mute, unmute — the normal conferencing stuff.

• Then came Content Tracks.
  What if someone could bring a locally recorded audio or video part into the room itself, instead of just screen-sharing or playing it separately?

• Jam Mode was the next question.
  If several people each brought a part, could we bring those parts together as one shared session?

• I wasn't trying to solve live internet jamming.
  Everyone playing into microphones and reacting to each other in real time is a much harder latency problem. These recorded tracks still go through LiveKit, so latency is still there; the interesting challenge is how closely we can coordinate them.

That actually matches how a lot of remote music collaboration already happens — people record their own parts or stems separately. The twist here was to see if those parts could come together within the meeting experience itself.

A different kind of system underneath

The room looks fairly simple, but underneath it I had to get comfortable with a different set of system-design problems.

• Don't let LiveKit become the whole application.
  We kept the media-specific code behind an adapter, so the rest of the product could think in terms of rooms, participants and media rather than LiveKit itself.

• A participant is more than camera + microphone.
  Once Content Tracks came in, the same person could also publish a recorded music or video stream. That immediately raises questions about state, media lifecycles and how all those streams reach everyone else.

• “In sync” has layers.
  Jam Mode can schedule a common start and count-in, but browsers, buffering, network paths and media latency still have their say.

This was the level at which I found myself working most with the coding agents — understanding the system, separating concerns, and knowing when a design needed another look.

Building differently with coding agents

This project was also me asking: how far can I take an idea when I combine the way I think about products and systems with coding agents?

• I wasn't suddenly becoming a WebRTC or React coder.
  I worked more at the design level — understanding the system, questioning choices and using other LLMs when I wanted another view.

• But unfamiliar technology became much more approachable.
  I still needed to understand streams, browser audio, room state and system boundaries well enough to have a useful design conversation.

• Even the demo became another small engineering exercise.
  I scripted interactions, coordinated media and used programmable tools around the recording and final video.

For me, that was the interesting shift: the agents could implement a lot, but I still needed to understand enough to direct the build.

Tech & engineering snapshot

This is something I can actually use myself, or with a small group of friends and collaborators. I just wasn't building for large-scale usage, so I kept the stack fairly lean while still giving the product enough structure, testing and engineering discipline to be dependable for that scope.

Area	What I used
Application	Next.js 15, React 19, TypeScript
Real-time media	LiveKit / WebRTC
Audio	Web Audio API
Identity	Supabase Auth
UI	Tailwind, shadcn, Radix
Testing	Vitest, Testing Library, Playwright
Build & deployment	GitHub Actions, Vercel

The repository eventually grew to 1,401 tests across 154 files, including unit, integration and browser-level testing.

The jam can still get tighter

There are really two things I’d like to play with next. First, get much more precise about the timing of the recorded parts and see how far that can be tightened. Then start pushing toward live participation — someone actually singing or playing into the room. At that point it isn’t only the network anymore; the mic, device, browser and local setup all start affecting what everyone hears. That feels like the next interesting problem to explore.

For me, that was probably the most interesting part of Swara Lounge — getting into a space I hadn't worked with deeply before, understanding enough to question and shape it, and then using coding agents to actually take the idea end to end.