Problem
Every night, a sports card seller makes the same call: list, hold, or feature. They check recent comps on 130point. They scroll PSA's pop report. They glance at Card Ladder. Then they trust their gut about which Prizm Silver to surface in their next live show, what to ask for it, and whether the category is too crowded to bother.
That decision is where margin lives. The same card listed at the right time, at the right price, in front of the right audience can outperform the same card listed two days later by a meaningful margin. But none of the existing tools tell a seller what to do. They tell a seller what happened.
Industry gap
Most sports card tooling stops at description. Price trackers like 130point and Card Ladder show recent comps. PSA and Beckett publish population reports. eBay, Goldin, and Fanatics Collect publish completed sales. Sports stat sites like Basketball Reference publish game logs. None of them connect those four layers into a single decision.
Hothand explores what that connecting layer would look like — not as a product, but as an analytics framework. The thesis is that event-driven sports performance combined with card-side scarcity and saturation can identify which players, card categories, and listing windows are most likely to convert into demand. Existing tools track outcomes; Hothand explores recommendations.
Project thesis
Can recent sports performance signals — combined with card-side scarcity, saturation, sales velocity, and engagement data — help sellers identify which players, card categories, and listing windows are most likely to convert into marketplace demand?
Data
The dataset is fully synthetic and generated by a deterministic Python simulation. No real marketplace data, no real player names, no scraped sources. The simulation produces 15 tables across four conceptual layers: league structure, game performance, card-product attributes, and marketplace activity.
The two-season simulation generates roughly 985,000 rows across 15 tables in its default "small" mode (designed to run on a laptop in about a minute), or roughly 3 million rows in "full" mode. Tables include teams, players, games, per-game stat lines, daily player momentum signals, card products with attributes (type, rookie status, serial-numbered, parallel), grading population proxies, market comps, listings, sales, engagement events, live show sessions, seller inventory, and generated recommendations.
A per-player momentum signal decays daily and gets bumped by above-average game performances. Listings, sales prices, and sale velocity all respond to that signal — which is what makes the downstream analytics interesting. The simulation is documented in detail in methodology.md in the repo.
Method
Hothand is structured around five modules, each layering on the one before it. The first three turn raw data into signals. The fourth turns signals into recommendations. The fifth puts the recommendations to work.
Metrics
Eleven metrics power the modules above. Each is documented in metric_definitions.md with formula, rationale, and a worked example. The headline list:
- Player Momentum Score — daily decay-based heat indicator
- Demand Index — marketplace-side confirmation of momentum
- Sales Velocity — sales per active listing per week
- Listing Saturation — active listings divided by recent sales
- Scarcity Score — population-weighted, rookie/serial/auto-aware
- Momentum Premium — OLS-fit slope of price vs momentum
- Price Volatility — coefficient of variation on recent sales
- Engagement-to-Sale Conversion — sales / engagement events
- Card Opportunity Score — the 0–100 composite
- Recommended Price Band — low / mid / high
- Live Show Priority Score — per-item live-show slot ranking
NBA + cards + market
+ recommendation logic
DuckDB
Dashboard
A six-page Streamlit dashboard sits on top of the DuckDB database. Each page maps to a piece of the seller workflow.
- Executive Overview — market summary, top opportunities, demand index trend, recommendation tile counts
- Player Momentum — hottest players, top movers, breakout watchlist
- Card Opportunity — sortable scoring table with score-breakdown waterfall
- Listing Recommendations — tabbed view of List Now / Watchlist / Hold / Avoid with price bands and reasoning strings
- Live Show Planner — pick a seller, pick a show length, get a ranked running order
- Methodology — synthetic-data disclaimer, formulas, weight sensitivity charts, limitations
Findings
The simulation is designed so the analytical machinery surfaces a small number of clear patterns. Once the dashboard has been run end-to-end and screenshots are captured, this section will be filled in with the actual numbers from a single, reproducible run.
· share of catalog labelled List Now / Watchlist / Hold / Avoid
· observed momentum-to-demand lag (synthetic)
· observed price uplift across demand bands (synthetic)
Recommendations
What the system would tell sellers, in plain English. Filled in after running the dashboard against the generated dataset.
· how many cards land in each label bucket
· which categories appear most often as List Now vs Avoid
· weight-sensitivity observations (does Top 20 shift much under different weight schemes?)
What I learned
This project helped me think through how analytics becomes a seller-facing decision system, not just a dashboard. The hardest part wasn't the SQL or the scoring — it was the schema design. Splitting static card attributes from time-series momentum signals from grade-specific population data was the decision that made every downstream query clean. Get the data model right and the analysis falls out naturally; get it wrong and you fight the data forever.
The other thing the project surfaced is how much value lives in the last mile — the layer that maps a 0–100 score to "List Now," that converts a price elasticity into a price band, that turns a ranked list into a live show running order. That last mile is the difference between an analytics project and a decision support tool. It's also where the rule-based code is intentionally simple, auditable, and replaceable — a real-data version of Hothand would swap the rules for a model trained on actual conversion outcomes.
Limitations
A few things to be honest about. First, all data is synthetic and the patterns reflect simulation parameters, not real-world dynamics — magnitudes don't transfer to actual sellers without validation. Second, the simulation is daily-granularity; real marketplaces operate at minute scale, and a lot of the within-day pricing dynamics are invisible here. Third, the implementation is single-sport (NBA) and single-product-type (cards) — the framework generalizes, but the code doesn't, yet. Fourth, the recommendation logic is rule-based with hand-tuned thresholds; a real-data version would use a model.