GitHub, TypeScript, Next.js, Tailwind CSS, GSAP, Turso, Vercel • 2026
BLURDLE
Project Overview
Blurdle is a daily music-guessing game where you try to identify an artist through a progressively de-blurring album cover, with five guesses to get it right before it's fully revealed.
The idea started from liking Wordle-style daily games, the kind where everyone gets the same puzzle and can compare results with friends the next day, but built around album art instead of words. Guessing an artist from a heavily corrupted cover is genuinely fun to get right, and watching the image slowly clear up with each wrong guess adds some tension without making it too easy.
Each day's artist and cover image are pulled from the iTunes Search API and stored in a database rather than fetched live on every visit. This keeps every player on the same day looking at the exact same puzzle, and avoids hammering the iTunes API with repeated requests every time someone loads the page. The corruption effect itself is done with a staged sequence of CSS filters (blur, contrast, and brightness), stepping down in intensity with each wrong guess so the cover becomes more legible over the five attempts.
Accounts don't use normal password auth. Instead, users can transfer their account to another device using a temporary 6-digit code generated on demand, so there's no password to remember or reset. If someone is only signed in on one browser/device and chooses to sign out, their account gets deleted after a warning, since without a transfer code already generated, signing out would just leave an orphaned account nobody could ever get back into.
Next.js with TypeScript keeps the fetch/store logic and the game UI in one codebase, deployed on Vercel. CSS filters were used instead of canvas-based image processing to keep things simple and fast in the browser, no server-side image work needed for the blur transitions.
The hardest part was making the transfer code system actually safe to use. A 6-digit code is short enough to type easily, but that also means it's short enough to guess if there's no protection around it, so the code needed to expire quickly and only work a limited number of times before it's invalidated. There was also the question of what happens if two devices try to redeem the same code at nearly the same moment, which needed a check to make sure only one of them can actually claim the account and take over the session, since letting both through would let two different devices control (and lose track of) the same streak and stats data.