project breakdown
inside the project
this page explains what the app is made of, what happens when someone creates a room, and why the technical structure is simpler than it might look from the outside.
overview
this project is a lightweight watchparty app for people who just want to open a room, send a link, and start watching together. the goal was to remove the usual friction: no account wall, no bloated dashboard, and no confusing setup before the room becomes useful.
it is built as a modern web app, so everything important happens directly in the browser. the site handles room creation, live audio and video, screen sharing, chat, and responsive layouts for phones and laptops.
the stack
- next.js handles routing, rendering, and server endpoints
- typescript keeps the app logic typed and easier to maintain
- livekit powers the real-time room layer for audio, video, screen share, and chat
- custom css modules shape the visual design instead of relying on a heavy ui framework
what happens when you start a room
when someone presses the main button on the landing page, the app creates a room id and sends them to a dedicated room url. from there, the pre-join screen collects the person's name and checks their microphone and camera settings.
after that, the browser calls a server route to request connection details. that server route creates a temporary access token, and the browser uses it to join the room. this is the safe part of the flow because the private credentials stay on the server instead of being exposed in the client.
how the live room works
livekit takes care of the hard real-time problems. it manages who is connected, whose microphone is active, who is sharing a screen, and how audio and video streams are moved between people in the room.
the watchparty code mainly decides how to present that information. if a screen share is active, the shared screen becomes the main focus and the participant videos move into supporting positions. if nobody is sharing, the room switches to a participant-first layout instead.
how the interface is organized
- a landing page creates and launches new rooms
- a pre-join step lets people set their name and devices before entering
- the room ui includes chat, call controls, a timer, and a share-link action
- the layout adapts across desktop, tablet, and mobile so the controls stay usable
- screen-sharing mode and gallery mode use different compositions for readability
why there is still server code
even though this feels like a browser app, there is still a small but important server layer. that layer creates room connection details and signs temporary access tokens. without that step, private keys would have to live in the browser, which would be a bad idea.
in simple terms, the server is the gatekeeper. it does the sensitive work once, sends the browser only what it needs, and keeps the rest hidden.
what was customized
this is not just a default starter template with a new logo. the landing page, room visuals, dark palette, responsive behavior, chat interactions, room actions, and mobile layout were all adjusted to make the app feel faster, cleaner, and less annoying to use.
a lot of the work went into removing edge-case friction: chat behavior on phones, screen-share focus, safer room-link sharing, more readable dark colors, and room controls that stay visible on smaller screens.
plain english version
this app has three jobs. first, it creates and routes people into rooms. second, it uses livekit to run the actual real-time call. third, it wraps that with a cleaner interface so the experience feels simple instead of technical.
if you ignore the implementation details, the whole system is basically: create room, get safe access, join room, share screen, watch together.