Deck Den
DeckDen is a full-stack deck-tracking app built for players who don't stop at one game — bringing real authentication with passkeys, live card search, public profiles, and an MCP server for AI assistants together in a single clean, fast experience instead of a different siloed app per game.
About the Project
DeckDen was built around a problem most TCG tools ignore: they're built around the game, not the player. Most players who are into Yu-Gi-Oh!, Pokémon, or whatever else are into more than one — but every existing tracker forces a separate account, a separate app, a separate identity per game. DeckDen flips that. One account, one public profile, every deck you've built across every game, all in one place — whether you're theory-crafting something new or just want a clean record of what you're playing.
How its built
DeckDen runs on a real production stack, not a demo one — Next.js, React, TypeScript, and Tailwind CSS on the frontend; FastAPI, PostgreSQL, and SQLAlchemy on the backend. Authentication is genuine: hashed passwords, JWT sessions, single-use expiring reset tokens, and self-service account deletion that actually cascades through a user’s data instead of leaving orphaned rows behind. Passkeys were added alongside password login, not in place of it. Players sign in with their device’s fingerprint, face, or PIN, built on WebAuthn with single-use challenges, and every failed attempt returns the same response so nothing reveals whether an account or a passkey exists. Card search pulls from three separate live data sources — two official third-party card databases, and a self-built scraper and database for the one game with no public API at all.
Open to AI Assistants
Players can create a read-only access token on their account page to let an AI assistant read their decks, and disconnect it any time. A token works only on three read endpoints, is shown once, and is stored only as a SHA-256 hash. It expires after 90 days without use, and a password reset disconnects every token. On top of those tokens, a separate MCP server built in strict TypeScript with the Model Context Protocol SDK and zod lets an assistant like Claude Desktop use two tools, list_my_decks and get_deck. It only passes along the fields an assistant needs: no email, no image URLs, and no owner info.
Practical by Design
DeckDen isn’t a local demo — it’s deployed for real, with a Next.js frontend on Vercel and a FastAPI backend and PostgreSQL database on Render, connected end to end with production-grade CORS and environment configuration. When Railway’s free credits ran out, the backend and database were rebuilt on Render, verified end to end, and the old deployment was decommissioned. Transactional email runs through a verified custom sending domain rather than a shared sandbox, so password resets reliably reach real inboxes. The whole stack runs in Docker locally, and GitHub Actions runs lint, typecheck, and automated tests on every pull request: 111 backend tests, 68 frontend tests, and 157 for the MCP server, not just manual click-through testing.
Built to Extend
DeckDen was built to extend, not just to ship once. Adding a new game means adding a search source and a game entry, not restructuring the app — the self-built Union Arena database already proves the pattern works even without an official API to lean on, and a single flag can pause a game, as Pokémon is paused for now, without touching anyone’s existing decks. Deck metadata like optional play-style tags was added without touching the surrounding architecture, passkeys were built as an addition to password login instead of a replacement, and the same card-focused UI scales cleanly whether a deck has three cards or three hundred. Next up are card tools for the MCP server, semantic card search, and rate limiting.
Polished UI, Serious Engineering Underneath
Every part of DeckDen — the poster-style deck cards, the click-to-zoom card view, the consistent dark theme — was built to feel simple to use. Underneath that, it’s handling real authentication security with passkeys and read-only access tokens, real race conditions caught and fixed through actual production testing, and a real deployment with its own DNS, environment, and CORS configuration to get right. The tests get the same scrutiny: breaking the code on purpose, 21 deliberate bugs in the passkey flow alone, confirmed that each one was caught. The result is an app that reads as effortless on the surface, with the actual engineering to back it up underneath.
