Riftbound Deck Manager: Public Demo, Private Workspace
TL;DR
Riftbound Deck Manager is live with a public demo path, private workspace boundaries, and deck verification that accounts for cards used across multiple decks.
Benjamin Hyde
Education Leader & AI Builder
Honestly, this one started pretty selfishly; I'm a bit of a card game nerd and my collection had quietly gotten out of hand. I needed something to actually track what I owned, and nothing off the shelf quite fit the way I think about it.
The real push came when I decided to launch a tabletop card game club at school for our geekier students. Suddenly I wasn't just managing my own collection — I was building out a stack of decks for students to play with, all pulling from the same card pool. The moment you're juggling that many decks at once, knowing which copies are already committed somewhere else stops being a nice-to-have and becomes genuinely critical.
So I built Riftbound Deck Manager. It's live at https://benjaminhyde.com.au/riftbound — and because I wanted to be able to demo it without handing over the keys to my actual collection, I split the experience from the start: open demo routes anyone can explore, and a private workspace for the real management side.
What shipped
The public side includes /riftbound as the main entry, then /riftbound/cards, /riftbound/decks, and /riftbound/inventory for demo browsing.
Those routes are intentionally safe to click around in. Anything persistent or account-specific stays in the private workspace mode.
The key challenge
The hardest problem was deck verification. Validating one deck in isolation sounds fine until the same card copies are already committed elsewhere.
I had to make the checks cross-deck aware, so the app shows genuinely available copies after existing allocations. That keeps legality and availability feedback honest.
How it is deployed
On the portfolio site, /riftbound traffic is routed to dedicated frontend and backend services. It feels integrated on one domain, but operationally it's separated where it needs to be.
The backend runs as a Python API (Uvicorn) with SQL-backed data for cards, inventory, and deck records, with public-safe reads separated from authenticated writes.
Build Notes
Approach
Build in two modes from the start: public demo routes for exploration and a private workspace for persistent operations.
Tools Used
Next.js, Python API (Uvicorn), SQL database, Docker
What Worked
The public/private split made sharing easy, and cross-deck tracking made verification feedback far more trustworthy.
What Failed
No major launch failures, but validation edge cases and clearer rule-explanation UX are still ongoing work.
What's Next
Improve validation messaging, tighten performance on large filtered views, and keep hardening import/export guardrails.