That game is RarestPick: https://rarestpick.com/ (free, no account).

The format: 7 prompts a day, 20 seconds each, everyone gets the same set. You type a free-text answer, and the less common your correct answer is among all players, the more points you get. A new set goes live at midnight Eastern Time.

It's inspired by the rare-answer daily games that have been popping up lately, and the codebase started from the MIT-licensed openkrillion project. The question bank, scoring implementation and UI are my own, and it isn't affiliated with Krillion. This post covers the parts that turned out to be the interesting engineering problems.

Problem 1: you need complete answer lists

A multiple-choice quiz needs one right answer. A rare-answer game needs every right answer, because the whole point is that people go looking for the obscure ones. If someone types "Comoros" and the game says "not on our list", the game is broken.

Hand-writing hundreds of complete lists isn't realistic, so the lists are generated from Wikidata with SPARQL. A question is basically a prompt plus a query. The general shape looks like this:

SELECT ?item ?label (GROUP_CONCAT(DISTINCT ?alt; separator="|") AS ?aliases)
       ?article ?sitelinks WHERE {
  ?item wdt:P31 wd:Q6256 ;      # instance of: country
        wdt:P30 wd:Q15 .        # continent: Africa
  ?item rdfs:label ?label . FILTER(LANG(?label) = "en")
  OPTIONAL { ?item skos:altLabel ?alt . FILTER(LANG(?alt) = "en") }
  OPTIONAL { ?article schema:about ?item ;
                      schema:isPartOf <https://en.wikipedia.org/> . }
  ?item wikibase:sitelinks ?sitelinks .
}
GROUP BY ?item ?label ?article ?sitelinks
ORDER BY DESC(?sitelinks)

Swap the triple pattern and you get a different question: dog breeds, chemical elements, Pixar movies, and so on. The game currently has 8 categories: geography, movies & TV, food, animals, sports, music, science and history.

A few lessons from doing this:

• skos:altLabel is gold. Wikidata aliases give you "Swaziland" for Eswatini and "Ivory Coast" for Côte d'Ivoire for free.
• Wikidata is crowdsourced, so class membership is messy. P31/P279 (instance of / subclass of) are sometimes missing or wrong, so a query can leak odd entries or miss obvious ones. I lean on items that have an English Wikipedia article and run automated checks on every list. The checks cover list size, ambiguous labels, aliases that collide with another answer, and duplicate questions.
• Avoid "current" anything unless the prompt is pinned to a date. Lists that change over time make for angry players.
• Players are the final QA. There's a "My answer should count" button on the result page. Missing answers get reported and can be added for future players.

Problem 2: matching messy free-text input

You have 20 seconds and a phone keyboard, so people make typos. The matcher goes roughly like this:

1. Normalize both the input and every answer/alias. That means Unicode decomposition to strip accents, lowercasing, & → and, dropping punctuation and spaces, and dropping a leading "the / a / an".
2. Exact match against the normalized canonical answers plus the alias index.
3. Fuzzy fallback for small, unambiguous typos, so "Nigria" becomes Nigeria. The correction is shown back to the player, so it's transparent.

The important word is unambiguous. Short inputs, or inputs that sit close to two different valid answers, get rejected instead of guessed. A wrong answer doesn't lock you out either. You get "Not on our list, try again" and the clock keeps running.

Problem 3: rarity, and the cold-start problem

Scoring is simple once you have data: count how many players picked each answer and turn the share into a tier.

The problem is day one. A brand-new question has zero plays, and a brand-new game has very few players. With 3 players, every answer is "rare".

The fix is a seed estimate from public Wikipedia signals. For each answer I use the page's views, the number of inbound links, and the number of language editions. Popular things (Nigeria, Egypt) get a big share of an imaginary reference crowd, and obscure ones get a tiny share. The real count for an answer is then roughly:

count = seed_count * seed_weight + real_count

seed_weight starts at 1 and fades as real plays accumulate, until scoring is driven purely by what real players typed. Fame on Wikipedia is a decent proxy for "what comes to mind first". It's not perfect, which is why it only covers the cold start.

Because shares move as more people play, scores during the day are provisional. Leaderboard scores are recalculated every ten minutes and freeze at midnight ET.

Stack

• Cloudflare Workers for the app and API. The server owns the timer: there's a 3-second reading phase, then a 20-second answer window enforced server-side with a small network grace period.
• Cloudflare D1 (SQLite) for questions, answers, the alias index and plays.
• An offline build script runs the SPARQL queries, pulls the Wikipedia stats, computes seeds, runs the checks and imports the result into D1.
• No accounts. A random device ID is enough to compute rarity and keep one daily run per player.

There's also an Unlimited mode by category for practice (3 free rounds a day, optional one-time unlock). It never touches the daily leaderboard, and paying doesn't change scoring.

What I'd do differently

• Start the answer-report loop earlier. Players find gaps in Wikidata lists faster than any automated check.
• Spend more time on prompt wording. "Name a cheese" is easy to query. Deciding whether a regional variant counts is a product decision, not a data one.

Try it

If you like weird data problems or just want to beat the crowd, today's puzzle is at https://rarestpick.com/. I'd especially love reports of answers you think are missing or questions that feel ambiguous. That feedback goes straight into the answer lists.