A 20-year-old card game came back into print, a secondary market formed around it overnight, and no pricing tool covered it. I built one in a week. warlord.market is live, indexed, and the best coverage of this game anywhere.
Impact
- 358 cards — full coverage of the Into the Accordlands rerelease
- 191 clicks from 1,716 impressions at 11.1% CTR, average position 10.2
- Card pages convert at 21% CTR in search results, the strongest at 34–37%
The problem
Warlord: Saga of the Storm is a 20-year-old TCG that Kingswood Games recently rereleased. A small, devoted community came back online, and a brand-new secondary market formed around 358 cards spread across decades of printings.
None of the existing TCG pricing tools cover Warlord. The eBay listings that do exist skew optimistically high, because sellers in a thin market list aspirationally and cards sit unsold for months.
I wanted a single place to see what every Warlord card actually trades for, across every source.
What it does
Every card gets a detail page that renders the printed card faithfully alongside its current pricing across every active eBay listing and every licensed retailer that stocks it. Buy links route through tracked affiliate URLs. The catalog updates daily; pricing refreshes hourly. Filtering, condition ladders, and a per-source breakdown are one click away.
The interesting problems
The printed card is sacred
The detail page has one non-negotiable rule: it must look like the card on the table, not a generic CMS template. Frame color, faction badge, rarity icon, art crop.
So I built a per-card override system. Any time the upstream data disagrees with the physical card, the card wins. Faithfulness is a product decision, not a backend detail.
Active prices lie in a thin market
Five active listings of the same card can span $4 to $80. Showing those raw numbers without context misleads collectors, so I wanted 30- and 90-day median sold prices next to the asking prices — the actual alongside the aspirational.
That data sits behind an eBay API that requires business approval: an affiliate partnership, then a vetted developer questionnaire, then a separate growth check. The gate is doing real work; the data is sensitive enough to deserve it. I shipped v1 on active listings with the sold-price layer ready to switch on, because the site already beats every other Warlord resource on coverage alone.
Condition needs translating
Condition is the second most important fact after price, but eBay returns cryptic codes — "NM/M", "LP", "MP/HP" — that mean different things to different sellers. I normalized them into a five-tier ladder with consistent tooltips, and tinted each badge to its storefront's brand color so you can see the source without reading it. Small visual move, large clarity payoff.
Stale data is worse than no data
The pricing pipeline runs on tiered schedules: eBay listings hourly, storefront prices every six hours, the catalog daily. New foil variants auto-create when retailers add them. Every price carries a "last updated" stamp, because in a thin market a confident wrong number is worse than an honest gap.
The design loop
When a UI question had three or four viable shapes — how to show many sellers on one card, how to render the condition ladder, how to lay out the filter sidebar — I'd have Claude wireframe the options in Figma side by side via the figma-console MCP server. I'd describe the constraints, get four labeled frames with real layouts, and pick one. The decision loop went from sketching four versions over an evening to seeing four versions in three minutes.
The same setup handled design system work after launch. Pointed at the live site and the codebase, it rebuilt the Figma library to mirror what shipped: tokens, component variants, color scoping. The Figma file is a mirror of the site now, not a parallel-universe approximation of it.
Search performance
- Clicks
- 191
- Impressions
- 1,716
- CTR
- 11.1%
- Avg. position
- 10.2
All 28 days as a table
| Date | Clicks | Impressions |
|---|---|---|
| 2026-08-10 | 6 | 148 |
| 2026-08-11 | 2 | 43 |
| 2026-08-12 | 7 | 63 |
| 2026-08-13 | 7 | 44 |
| 2026-08-14 | 9 | 58 |
| 2026-08-15 | 10 | 66 |
| 2026-08-16 | 8 | 106 |
| 2026-08-17 | 8 | 82 |
| 2026-08-18 | 11 | 55 |
| 2026-08-19 | 5 | 56 |
| 2026-08-20 | 7 | 49 |
| 2026-08-21 | 4 | 41 |
| 2026-08-22 | 11 | 86 |
| 2026-08-23 | 6 | 52 |
| 2026-08-24 | 3 | 41 |
| 2026-08-25 | 10 | 49 |
| 2026-08-26 | 4 | 46 |
| 2026-08-27 | 6 | 52 |
| 2026-08-28 | 3 | 36 |
| 2026-08-29 | 3 | 39 |
| 2026-08-30 | 7 | 67 |
| 2026-08-31 | 9 | 59 |
| 2026-09-01 | 8 | 60 |
| 2026-09-02 | 9 | 63 |
| 2026-09-03 | 5 | 90 |
| 2026-09-04 | 9 | 47 |
| 2026-09-05 | 6 | 52 |
| 2026-09-06 | 8 | 66 |
What I'd do differently
The sold-price API questionnaire should have gone in on day one, in parallel with the build, not after launch. I'd flagged exactly this pattern in CardScan, where I also went eBay-first because it was the more interesting engineering problem, and I made the same call again here for the same reason. The lesson is sticking now: find the data gate first, build the product second.