MicDrop — the living room is the venue.
Karaoke split across two screens. A TV or laptop becomes the stage; every phone in the room is a controller. There is nothing to install and nothing to type — the stage puts a QR code on screen, and that is the entire join flow.
Two screens
Stage · handsetKaraoke on a laptop is one person hunched over a keyboard while everyone else waits. The split fixes the social problem before it touches the technical one: the big screen holds the lyrics, the queue and the room code, and the phones hold everything a person actually wants to do — search, queue a track, take the mic next. Nobody hands a laptop around, and nobody installs anything to sing one song at a party they were dragged to.
One room, in step
A room is a set of sockets that must agree on one running order. Every handset can add to it, the server keeps the order round-robin so nobody sings twice before anyone sings once, and the stage is the only screen that plays — shared state with many writers and one reader that matters. Socket events are validated before they are trusted and handled statelessly, decoupled from the transport, so a reconnecting phone rejoins a room rather than forking it.
One running order per room, written from any handset and rendered identically on every screen that is watching it.
Listeners are removed on disconnect and references to departed guests dropped, because a party app that leaks a Map entry per guest dies on the night it is busiest.
Documents are never returned straight from the database — payloads are projected through DTOs, so internal fields cannot leak into a room full of strangers' phones.
Build
As deployedEasiest way to judge it is to open a room.
Put it on the nearest big screen and point a phone at the code. The join flow is the product.