tcgVault

A portfolio dashboard. Total value, cost basis, and unrealized profit and loss; breakdowns by item category and by game; top movers; and a value-over-time chart built from a real daily history rather than a single live lookup.

Three genuinely different kinds of item. Raw singles, graded singles (which carry a grading company, a grade, and a certificate number), and sealed product. They price differently and they behave differently, so each carries its own purchase price and its own profit and loss.

Pricing that runs itself. A nightly job snapshots every price so the portfolio has genuine history. Behind it: a 24-hour cache, a stale-data indicator that says so plainly when the job hasn't run, and a circuit breaker that stops the app hammering the price vendor once it starts refusing requests. That last one exists because an earlier version got me rate-limited.

Set completion tracking. Checklists per set, progress as you fill them, what's still missing, and what it would cost to finish.

Also, in less detail:

Currently building: a seller-channel importer that reads my own marketplace listings back in and flags the ones whose prices have drifted away from the market. Three of its seven subtasks are done.

These are screenshots of the running app, captured against a seeded demo database. Every card, price, and total below was invented for the purpose — none of it is my collection.

The repo is private because its history is. Four months of commits carry real configuration and real values, and scrubbing a git history properly is its own project — one I haven't done yet. So the honest answer is that the code isn't public because the past of it isn't, not because there's anything clever in it worth hiding. The app is above.

Every change goes through the same pipeline — planned, built, reviewed by two independent AI reviewers and an automated reviewer on the pull request, then merged. That process is a project in its own right, and it has its own page.

The importer that would have worked right up until the first expensive card. I wrote a CSV importer to pull in listings from a marketplace export. It parsed prices with a function that silently gives up on any number containing a thousands separator — and one bad row aborted the whole file. Every test passed, because every card in the sample export I built the fixtures from was cheap enough that no price ever reached four figures. The bug was sitting there waiting for the first $1,000 card. A reviewer caught it; the test suite never would have. A green suite proves your code handles the reality your fixtures came from — not the reality it's about to meet.

The nightly job that reported success for a day while doing nothing. For a day, the nightly price snapshot failed every time it ran — and the run log recorded a success every time. It was logging that the job had been handed off, not that it had finished. So a run that died instantly wrote a clean "success" straight away, while a run that actually worked outlived the window the log was written in and left no record at all. Broken looked healthier than working. Monitoring the wrong thing is worse than not monitoring, because it sells you confidence you haven't earned.