Full-stack engineering · Personal project
One Piece TCG Shelf
A deployed application for browsing cards, managing a collection, tracking estimated value, and sharing a collector profile.
Built from my experience as a collector
As a One Piece collector, I understand the challenge of tracking card variants, graded cards, and changing market prices. That experience informs how I build TCG Shelf.
View my personal collection on Collectr ↗See the application in use
My contribution
I built the application across the React/Next.js interface, TypeScript APIs, Supabase authentication and storage, PostgreSQL data model, and server-side pricing workflow. The product includes collections, public profiles, trade offers, and a storefront. The source repository is public; this case study explains the architecture and the engineering decisions behind the application.
Stack: Next.js, React, TypeScript, Supabase, PostgreSQL, Tailwind CSS, Vercel.
How the pieces connect
Browser
React interface
Application
Next.js routes + Auth
Data
PostgreSQL + RLS
JustTCG → server-side sync → cached market prices in PostgreSQL
- The browser presents the catalog, collection, and public profile interfaces.
- Next.js routes handle application requests; Supabase Auth supplies the user session.
- PostgreSQL stores catalog, collection, and pricing data, with RLS for owner-scoped access.
- The server-side pricing pipeline updates the cache from JustTCG; clients read cached prices.
Engineering decisions
Keep private collection data separate from public shelves
Problem: Collectors can share a profile without exposing every owner-only value.
Implementation: Supabase Auth identifies the user; protected APIs and PostgreSQL Row Level Security constrain owner data. Public API responses expose a separate, limited view.
Validation and tradeoff: The API documentation distinguishes public market prices from owner-only estimated collection values. This boundary needs both API and database verification.
Cache market prices on the server
Problem: A page load should not depend on a fresh external pricing request, and API credentials must stay off the client.
Implementation: A server-side JustTCG pipeline writes price variants to PostgreSQL. The interface reads the cache, with condition-aware selection and explicit handling for unavailable prices.
Validation and tradeoff: Unit tests cover preferred condition/printing, unrelated variants, and labeling graded cards with underlying raw-market prices. Cached prices can lag the market; they are estimates, not guaranteed sale prices.
Calculate collection value without hiding missing data
Problem: Quantities, user estimates, and missing market prices can produce misleading totals if treated identically.
Implementation: Valuation uses integer cents, multiplies unit values by quantity, prefers an owner's manual estimate, and tracks priced and unpriced items separately.
Validation and tradeoff: Unit tests cover quantity multiplication, missing prices, manual overrides, and ranking cards by unit market value.
A quick walkthrough
- Open the public catalog and search for a card or set.
- Inspect the card details and available market information.
- Authenticated collectors can add cards, adjust quantities, and build a public shelf. The private collection workflow requires an account.
The focused pricing, collection-value, and safe-redirect suites passed 13 tests on September 10, 2026. Next steps are broader end-to-end checks across multiple accounts, database-policy integration tests, and clearer price-freshness indicators. Cached estimates can lag the market; unit tests alone do not establish production-scale reliability.