INSIDE THE LAB / CASE STUDY 01
Building a collector's decision tool means getting the card, the evidence, and the record right.
IN DEVELOPMENT / PREPARING FOR BETA
01 / OVERVIEW
GrailLocker started after a card show with my son. He'd bought a card, then wanted to understand its value and whether he'd made a good decision.
I'm building a native iOS application to bring card identity, market context, purchase and trade analysis, and collection records into one workflow. The product direction spans sports and trading-card games; provider coverage is still being validated.
Collectors move between tools to identify cards, look up prices, compare a deal, and organize what they own. At a show, there's little time to check whether a price belongs to the exact set, parallel, or condition in front of you.
02 / THE PRODUCT
The card starts the workflow. The useful outcome is knowing what to do next, then keeping a record of the cards you acquire.
Capture the card and confirm its identity.
Understand pricing evidence and its source.
Compare a purchase, flip, or trade.
Buy, counter, pass, or trade.
Keep acquisition details in your Locker.
Card Show Mode focuses on the deal before acquisition. Collector Mode keeps the owned card, what you paid, and market history together. Deal Maker, Flip Opportunity, and Trade Analyzer are part of the product work in progress.
03 / ARCHITECTURE
Capture, identification, provider matching, and storage solve different problems. Keeping those responsibilities separate makes it easier to test a decision without changing a collector's records.
Provider matching checks catalog candidates against card identity.
Simplified view of implemented development components. The market-feed foundation has been piloted separately; complete app integration and automatic refresh are still being validated.
04 / ENGINEERING CHALLENGES
A subject and card number aren't enough. The matching resolver checks category, year, full release, number, and variant. Missing evidence stays unknown. An exact match needs one fully proven candidate; unresolved alternatives remain ambiguous.
The search adapter rejects overlapping requests and applies a cooldown after rate-limit responses. Diagnostic searches are explicit, with no automatic retry loop. That makes provider behavior easier to investigate without multiplying requests.
The market-feed importer validates rows before publishing and commits catalog updates together. If validation or publication fails, it preserves the current catalog. Provider product identity stays separate from a collector's owned copy.
A download time doesn't prove when a provider generated its data. The feed foundation keeps source dates, download times, and import times distinct. If the source date isn't supplied, it stays unknown.
05 / ITERATION & LESSONS
Two examples from the development work:
The lesson so far: a useful tool should be clear about what it knows, what it can't prove, and what the collector still needs to confirm.
06 / STATUS
GrailLocker is actively in development and preparing for beta. Matching and market-data components have dedicated development tests, while coverage and integration work continue.
The GrailLocker experience is still in development. Some screens shown are mockups or beta previews and may change before release.
This case study describes development work, not a claim that every integration is available in a released app.