TCG Haven Portfolio

Human-in-the-loop inventory and market tracking for small TCG businesses.

Comment

Inspiration

I run TCG Haven, a small trading-card business in Germany. A single card purchase can involve a marketplace CSV, an invoice PDF, several card databases, and cards that differ only by set, collector number, language, finish, or promotional stamp.

A wrong match does not only create a catalogue error. It can also distort inventory quantities, acquisition costs, market tracking, and later pricing decisions.

I started TCG Haven Portfolio to replace this fragmented spreadsheet workflow with a safer local application.

What it does

TCG Haven Portfolio combines purchase imports, card identity review, inventory, acquisition costs, and market observations in one workflow.

The purchase process has four clear stages:

  1. Import the purchase data
  2. Review card identities
  3. Confirm costs
  4. Finalize the order

Clear identities can be matched automatically through verified source relationships. When the available evidence conflicts or a specific printing is missing, the application does not guess. It explains what is known, asks for a human decision, and blocks unsafe inventory changes until the review is complete.

The application also allocates shipping and transaction fees to individual inventory lots.

Market observations can be extracted from screenshots. Suspicious OCR results are not silently corrected. The detected value, plausibility warning, and proposed correction remain separate until the user explicitly confirms the result.

How we built it

The application is a local Python and Streamlit system using SQLite, SQLAlchemy, and Alembic migrations.

The submitted repository contains a reproducible anonymized demo. Every reset creates a fresh temporary database, CSV, and PDF from public synthetic fixtures. It contains no real orders, customer data, Candidate database, or Production database.

The project existed as an internal prototype before Build Week and was substantially extended and hardened during the event.

I used GPT-5.6 through Codex for implementation, debugging, runtime hardening, OCR safety, UI and UX improvements, automated tests, Playwright browser scenarios, privacy auditing, and preparation of the reproducible submission snapshot.

I defined the real business problem, product requirements, identity rules, safety decisions, and practical acceptance tests. GPT-5.6 is not integrated as a hidden runtime service in the submitted application.

Challenges

The largest challenge was that a card name alone is not a reliable identity. The same name may exist in several sets or physical variants, while marketplace and catalogue sources may use different identifiers.

Another challenge was handling OCR values safely. For example, 1.002,00 € is technically a valid decimal value, even when the intended result may be 10,02 €. Automatically rewriting it would be dangerous, so the application treats it as a reviewable suggestion instead.

We also had to create a public demo that remained realistic while excluding all private business and production data.

Accomplishments

  • A complete purchase-to-inventory workflow
  • Automatic handling of verified card identities
  • Human-in-the-loop review for uncertain printings and variants
  • Cost allocation across inventory lots
  • Screenshot-based market observations with plausibility checks
  • 174 automated tests
  • Browser-based end-to-end validation with Playwright
  • A synthetic OCR benchmark covering 18 cases and 108 fields
  • Reproducible reset and launcher cycles
  • A privacy-audited public submission repository

What we learned

The most important lesson was that safe automation is not the same as maximum automation.

For financially relevant inventory data, a system should automate strong evidence, clearly explain uncertainty, and refuse to invent an answer when the sources disagree.

Codex was especially useful for running repeated implementation, validation, and hardening cycles while keeping the business rules explicit and testable.

What's next

The next steps are broader catalogue coverage, improved import adapters, stronger market-history analysis, and preparation for a controlled production migration.

The same human-in-the-loop architecture could later support additional trading-card games and other small retailers that manage products with complex variants.

Built With

Share this project:

Updates