Two things up front, because they shape the design: it is not a race (speed doesn't count, everyone can score on every track), and there is no built-in chat, so the easiest way to play is in a voice call with friends.

The code is on GitHub. Here are the parts that were the most interesting to build.

The stack

Next.js (React, TypeScript) on the front, Node.js + Express + Socket.io on the back, in one monorepo. There is no database: rooms live in memory on the server and disappear when the last player leaves.

1. Importing playlists from three platforms

The idea only works if a player can paste a link from the service they already use. Each platform needed a different approach:

• Deezer: the public API (api.deezer.com/playlist/{id}).
• Spotify: playlists are read from the public embed page, which exposes the track list in its page data. I used the official API only for albums.
• Apple Music: the playlist page is scraped with Cheerio.

An honest caveat: two of the three rely on page structures I don't control, so they can break when the platforms change them. That's the main maintenance risk of the project.

Never trust a pasted link

Players paste arbitrary links, and the server fetches them. Left unchecked, that is a server-side request forgery (SSRF) hole: someone could make the server call an internal address. So links go through a strict allow-list:

const ALLOWED_HOSTS = {
  deezer: /^(?:[\w-]+\.)?deezer\.com$|^deezer\.page\.link$/,
  spotify: /^(?:[\w-]+\.)?spotify\.com$|^spotify\.link$|^spotify\.app\.link$/,
  apple: /^(?:music|itunes)\.apple\.com$/,
};

The check runs on the hostname parsed by new URL, never on the raw text, so https://evil.com/?x=deezer.com and https://deezer.com@evil.com are refused. Only https without a custom port is accepted. Short links (spotify.link, deezer.page.link) are followed redirect by redirect, and every hop must stay on an allowed domain. There is a test file dedicated to this.

2. Typo-tolerant answers

Players type the artist and/or the title. The comparison is forgiving: case and accents are ignored, and everything that isn't a letter or a digit is stripped.

export function normalizeString(str: string): string {
  return str
    .toLowerCase()
    .normalize("NFD")
    .replace(/[̀-ͯ]/g, "")
    .replace(/[^\p{L}\p{M}\p{N}]/gu, "");
}

Artists are split on ,, &, feat., with… and each one is checked. Scoring is simple: 1 point for the artist (0.5 if there are several and you only find some of them) plus 1 point for the title. An autocomplete suggests names from the loaded playlists, which removes most typing errors.

The normalisation of each track is computed once when the game starts, not on every answer.

3. Non-Latin names

Many playlists mix scripts: Japanese, Chinese, Korean, Cyrillic. Players on a Latin keyboard can't type those, so each track also gets an "international" (romanised) name, and both versions are accepted. The pipeline is:

• Latin text stays as is.
• Anything with kana goes through Kuroshiro (Japanese reading, kanji included).
• Other scripts (Chinese, Korean, kanji alone…) go to an LLM through the Groq API, and fall back to local transliteration if the call fails or no key is set.

Only titles and artist names are sent to the API, never usernames or IP addresses. It's documented in the app's privacy page.

4. A server-driven game clock

Every player must see the same countdown, even with a laggy phone or a throttled background tab. Instead of counting down on each client, the server only sends two timestamps:

function getGameTiming(time: number, gameStartTime: number): GameTiming {
  return { gameStartTime, serverNow: Date.now(), time };
}

The client estimates the gap between the two clocks once, then derives the round, the phase and the time left from the current time:

const toGameClock = (timing) => ({
  startTime: timing.gameStartTime,
  offset: timing.serverNow - Date.now(),
  time: timing.time,
});

A round is time seconds of guessing, 5 seconds of reveal and 2 seconds of transition. Because the state is a pure function of the clock, a player who reloads the page or comes back from another app lands on the right screen without any "catch-up" message.

The limit: network latency is ignored, so clocks can differ by a few dozen milliseconds. Since speed doesn't affect the score, that's fine, which is one more reason the game isn't a race.

5. Disconnections and reconnection

On mobile, players switch apps all the time. Each player has a private ID stored in the browser; on reconnect the server swaps the socket and sends back the current state. A 5-minute grace period before a disconnected player is removed, and the host role is transferred if the host doesn't come back. One subtle bug class: a stale socket firing its disconnect event after the player has already reconnected on a new one. The handler ignores it when player.socketId !== socket.id.

6. Privacy by default

No database, no analytics, no ads. Room data is purged when the room empties. Other players never receive your reconnection ID or your playlist link, only a random public ID. The server also rate-limits per IP (room creation, playlist loads, bad room codes, simultaneous connections).

7. Testing with real clients

The backend tests start their own server and play games with real Socket.IO clients: answers and scores, host rights, identity, disconnections and reconnections, reset, mixed-script playlists, the link allow-list, and rate limits. Testing at the socket level caught more real problems than unit tests alone would have.

Try it

museek.xiao-web.com: free, no signup. It's a multiplayer game, so bring a few friends and a voice call. Feedback is very welcome, especially on onboarding and on playlist links that don't load.

Museek is an independent project, not affiliated with Spotify, Deezer or Apple.

I used an AI assistant while building the project and to help draft this post