Cardboard

Product Strategy · Competitive Parity Plan

Beat Slabfy at its
own feature set.

Slabfy's comparison article is winning SEO and getting cited by LLMs. It also happens to be a feature roadmap handed to us for free. This deck maps every Slabfy feature (plus CollX & Ludex table-stakes) onto Cardboard — and where we make each one better.

Slabfy features we already ship

Features to build

Delivery phases

New infra spend (rides existing stack)

Cardboard · thecardboard.app · local-first React 19 PWA + single Cloudflare Worker + Supabase + Card Hedge + Claude vision. Competitor: slabfy.com

Why this matters

They wrote the playbook. We read it.

Slabfy published "CollX vs Ludex vs Slabfy: Best Sports Card App" — a long-form article they wrote themselves. Two smart things happened.

SEO play

Ranks for the comparison query

Buyers searching "best sports card app" land on a page where Slabfy conveniently wins. Classic own-the-comparison content.

LLM pickup

Cited by AI assistants

Because it's structured, thorough, and comparative, LLMs quote it as a source — so it recommends Slabfy inside AI answers too. That's the real prize.

Our counter-play (free): the same article is a spec sheet. We emulate the features, then publish our own "Cardboard vs Slabfy vs CollX" page — and we get to truthfully say three of their headline features already ship in Cardboard today.

Cardboard vs Slabfy vs CollX vs Ludex

Head start

Where Cardboard already wins

Zero work required. These are live today and go straight onto the comparison page.

Slabfy headline feature	Cardboard equivalent	Status
Price Check at shows	Quick price check — scan → value, saving optional	Shipped
Grade-ladder ROI	`/ch/grades` ladder + "worth grading?" upside signal	Shipped
Real-time values	Card Hedge FMV + daily reprice + two-clock trust line	Shipped
Collection tracking	Full inventory + 3-act portfolio analytics	Shipped
— neither competitor has —	Movers feed · sell-signals engine · offline-first PWA · demo mode	Our moat

Translation: we're not starting behind. We're closing a gap on dealer tooling and eBay integrations while already leading on pricing intelligence and analytics.

The build list

Feature gap matrix

Eleven features, each tagged with its competitor source, complexity, and target phase.

#	Feature	From	Complexity	Phase
1	Fees-aware profit math underpins Slabfy's "full profit math"	Slabfy	Low	1
2	CSV export + import CollX/Ludex migration wedge	CollX Pro	Low	1
3	Card Show POS — events, cart, per-show P&L	Slabfy	Medium	2
4	Want List — app UI + schema	Slabfy	Medium	3
5	Want List 24/7 eBay monitoring + alerts	Slabfy	High	4
6	Flip Finder — eBay arbitrage w/ profit math	Slabfy	High	4
7	"Ask Fy" AI agent — chat + portfolio tools + slab ID	Slabfy	High	5
8	Consignment management — splits, payouts	Slabfy	Med-High	6
9	QR-code Storefront — public for-sale page	Slabfy (theirs "coming")	Medium	6
10	Binders / tags (+ set completion)	Ludex	Medium	7
11	eBay listing / repricing	Slabfy	Very High	Deferred

A0 · Prerequisite

The eBay API reality check

Everything eBay-flavored depends on getting this right. Good news: the read-only path is free and generous.

The workhorse

Buy Browse API

item_summary/search with app-level OAuth (client-credentials — no per-user consent). Free, 5,000 calls/day.

Hourly want-list scans ≈ 1,900/day
2-hourly flip scans ≈ 1,800/day
Comfortable headroom ≈ 1,300 calls

The gate

Account-deletion endpoint

eBay won't grant a production keyset until you host a public Marketplace Account Deletion endpoint (challenge/response).

Add GET/POST /ebay/account-deletion to the Worker (~30 lines)
One new secret: EBAY_VERIFICATION_TOKEN
Do this first — it blocks the keyset

Sold-price APIs (Marketplace Insights) are gated behind business approval — we don't need them. FMV already comes from Card Hedge.

Free upside: add the eBay Partner Network affiliate header on Browse calls and every alert / flip deep-link becomes a monetized link. Zero extra work.

A1 · Feature

Want List with 24/7 eBay monitoring

You describe the card you're hunting and your max price. The Worker watches eBay around the clock and drops matches into an in-app inbox.

How it flows

Add a want — manually, or one-tap from a Market mover / MoverDetailScreen. The eBay query string is built client-side by reusing the term-builder already inside ebaySoldUrl().
Sync — wants ride a new mirror of the proven cards sync pattern (last-write-wins, tombstones).
Cron scan (worker/src/scan.js, hourly) — pulls due wants, Browse-searches each under max price, de-dupes hits into ebay_alerts.
Alerts inbox — client pulls unread alerts on the existing 45s sync tick; badge + AlertsScreen with deep links.

Data model

Dexie v5: wants, wantTombstones, alerts. Supabase: want_list + ebay_alerts with a unique(want_id, ebay_item_id) guard so the same listing never alerts twice.

v1 cut line

US marketplace, fixed-price + auction, 20 active wants/user, hourly scan, in-app inbox only. Web Push is a later enhancement (needs iOS home-screen install).

Better than Slabfy: every alert row carries full profit context — the listing price vs our FMV, right there in the inbox.

A2 · Feature

Flip Finder — the arbitrage radar

Continuously flags cards listed under market, with the full buy-flip-sell math done for you.

The honest constraint: you can't "scan all of eBay" on 5k calls/day. So we scan where FMV is known and liquid — the Card Hedge movers already pre-warmed in KV every 6 hours. v1 restricts to graded slabs (PSA 9/10) because raw/parallel title-matching is too fuzzy to trust with money.

The profit math (per candidate)

fees_est = total × 13.25% + $0.30

ship_out ≈ $4.50

profit_est = fmv − total − fees − ship

Keep only rows passing a tunable FLIP_CONSTANTS block: MIN_PROFIT $20 · MIN_MARGIN 25% · title must contain player + year + grade (the fuzz guard).

Architecture

Global flip_candidates table — one scan serves every user, so cost stays flat as users grow.
2-hourly cron over KV-cached movers → zero extra Card Hedge calls.
FlipFinderScreen reads through marketCache.js — paints instantly, works offline.
48h expires_at cleanup — listings churn fast.

v1 → v2

v1: movers-derived slabs. v2: also scan your want-list players + your own portfolio's cards, with user-tunable thresholds.

A3 · Feature

"Ask Cardboard" — a portfolio-aware AI agent

Slabfy's "Fy" knows your cards, knows the market, and IDs slabs by camera. We already pay for Claude in the Worker — this is a natural strength to lean into, not a new dependency.

The clever bit

Client-side tool loop

Your portfolio lives in Dexie on your device, and the Worker has no user auth — so the Worker never executes tools. When Claude asks to use a tool, the client runs it locally, appends the result, and re-calls. Streaming SSE passes straight through the Worker.

Privacy bonus: portfolio data only ever transits the server as model context — never stored server-side.

Slab-ID by camera = zero new backend

The chat's "ID a slab" button reuses the existing /identify flow, injects the card JSON into the conversation, and the agent prices it via its tools + offers "add to inventory / want list."

The tool belt

get_portfolio_summary — reuses portfolioStats()
search_my_cards · get_card_detail — Dexie queries
search_market · get_fmv · get_grades · get_comps · get_price_history — existing market.js through the cache, so repeat questions are free + offline
get_movers · add_to_want_list · ebay_sold_link

Cost control (cloned patterns)

Same daily-cap KV counter as /identify, a per-IP rate-limit binding, max_tokens 1024, history truncated to ~20 messages, 6 tool-rounds max, and prompt caching so multi-turn chats are mostly cached tokens.

B0 · Build once, everything rides on it

Three cross-cutting foundations

🗃️

Dexie v5

One schema bump adds shows, sales, consignors, payouts, wants + new card fields. All null-defaulted — zero data migration.

🔀

Sync generalization riskiest

Today sync.js is hardcoded cards-only. Refactor to a table-driven SYNC_TABLES config with per-table cursors. Mitigation: refactor cards-only first (behavior-identical), then add tables one at a time.

🏪

A 5th "Dealer" tab

New DealerScreen hub: active-show banner, Want List, Consignors, Storefront, CSV. Keeps the three collector tabs clean; every dealer feature gets a home.

The iron rule for every phase: Supabase migration ships before the client — PostgREST rejects unknown columns on upsert, so a new client against an old schema breaks sync.

B1 + B2 · The compounding pair

Real profit math & Card Show POS

B1 · ships first

Fees-aware profit

Today profit = sale − cost in exactly two places. New fees.js adds channel presets and net-of-fees math:

Cash/Venmo/Zelle 0% Card reader 2.6%+$0.10 eBay 13.25%+$0.30 PayPal G&S 3.49%+$0.49

Presets prefill, never lock. The regression test: null-fee legacy cards must compute identically to today. Everything (portfolio, inventory summary, flip math) inherits real margins.

B2 · dealer bread-and-butter

Card Show POS

Cards stay the source of truth — each sold card carries its allocated price + sale_show_id, so event P&L is a pure live query and portfolioStats needs zero POS awareness.

Bundles / haggling — type the real total, app pro-rates by asking-price weight; shows discount vs asking.
Quick-scan to cart — scan the card a buyer hands you → it finds the inventory row.
Live revenue / profit header · by-channel · end-of-show summary + CSV.

Better than Slabfy: scan-to-cart + live per-line profit + discount analytics per show.

B3 + B4 · Business features

Consignments & the QR Storefront

Consignment management

Track cards owned by other people that you sell. Consignor with a split %, per-card override, and a payout ledger (owed = Σ their cut − Σ payouts).

Consigned stock excluded from your cost basis — shown as a separate line, sales counted as "your cut" only.
Per-consignor screen: in-stock / sold with split math / ledger + "Record payout" + "Send statement."
Must not ship before sync generalization — a one-device payout ledger is a trust bug.

B4 · Slabfy's is only "coming"

QR-code Storefront

A public, shareable page of your for-sale inventory. Share the link or flash a QR at a show.

Security by design: public reads come from a column-whitelisted Postgres view — never cost, fmv_*, or sale fields. Leaking a dealer's cost basis would be existential.
Worker serves GET /s/:slug as server-rendered HTML (no JS needed), 60s edge cache, on thecardboard.app.
Client-side QR (tiny qrcode dep). "Ask about this card" → prefilled mailto/SMS/Venmo.

Mandatory test: open /s/{slug}.json logged out and assert the response contains no cost / fmv / sale fields. This is a ship-blocker check, not a nice-to-have.

B6 + B7 · Growth wedge & organization

CSV migration & Binders

B6 · the conversion wedge

CSV export + import

Hand-rolled RFC-4180 (no dependency). Export inventory + sales with computed net/profit. Import with a column-mapping UI + CollX/Ludex header presets and a 5-row preview.

Every imported card tagged imported-YYYYMMDD → filter + bulk-delete = instant undo.
Imported cards flow into the existing pricing queue for market linking.

Marketing angle: "Switch from CollX in 5 minutes." This is how we pull their users.

Binders = tags

A tags array on each card (multi-entry index, jsonb in Supabase) — zero new sync tables. A binder is just a tag: "PC", "Show box A", "Grade candidates". Chip filters in inventory, tag editor in the card form.

Set completion: deferred. Card Hedge has no set-checklist endpoint — a wrong "87% complete" is worse than none. The tags-per-set groundwork is identical if/when a checklist source appears.

Execution

Unified phase roadmap

Dependency-ordered. Each phase is shippable on its own. Fees + POS compound; sync generalization is the pivot everything downstream waits on.

Start now, in parallel with Phase 1: apply for the eBay developer account + production keyset (there's an approval wait) and stand up the account-deletion endpoint. It hard-gates every eBay feature, so the clock should start immediately.

Fees math + Tags + CSV Low risk

Real profit margins, tag organization, and the CSV migration wedge. Only a user_cards ALTER — no Dexie bump.

depends on: nothing · gate: regression-test null-fee cards

Dealer tab + Card Show POS Medium

Dexie v5, the hub, POS/cart/summary screens, card-picker sheet.

depends on: Phase 1 (fees feed POS profit) · gate: hold the bundle-allocation line

Sync generalization Highest risk

Table-driven sync engine + 5 new Supabase tables + cursor migration. The pivot that unlocks everything multi-device.

gates: Phases 4 & 6 · gate: refactor cards-only first, then add tables one at a time

Want List UI + Consignments Medium

Synced want list + full consignor/payout/statement flow.

depends on: Phase 3 · gate: label "your cut" everywhere

eBay monitoring backend + Flip Finder Med-High

Hourly want-scan cron + alerts inbox, then the 2-hourly flip scanner + screen.

depends on: eBay keyset + Phase 4 · wildcard: eBay approval timing

Ask Cardboard AI agent Medium

/agent streaming route, client tool loop, chat UI, slab-ID reuse.

parallelizable any time after Phase 1 · cost caps clone existing patterns

QR Storefront Medium

Public view, Worker GET /s/*, storefront screen + QR.

depends on: Phases 1–2 · parallel to 3/4 · gate: data-leak test mandatory

Enhancements Droppable

Web Push alerts, EPN affiliate links, flip-finder personalization, binders screen.

depends on: Phase 5 · each independently optional

Requirements to deploy

What must exist outside the code

① eBay developer program

Production keyset → EBAY_CLIENT_ID / EBAY_CLIENT_SECRET secrets + the account-deletion endpoint live before keys are granted. Browse API: app token, 5k/day, free.

② Supabase migrations

CLI-first (Dashboard fallback per SOP): card ALTERs, 5 new user_* tables + RLS, want_list / ebay_alerts / flip_candidates, storefronts + public view. Migrate before shipping client.

③ Cloudflare Worker

New cron expressions (30 * * * * wants, 15 */2 * * * flips, keep movers prewarm), new secrets, agent rate-limit binding, KILL_EBAY + agent daily-cap counters, GET carve-outs for /s/* and account-deletion.

④ Domain, deps, spend

/s/* routes on thecardboard.app apex (QR carries the brand). One new npm dep: qrcode (CSV hand-rolled, Push uses WebCrypto). /agent rides the existing Anthropic key — no new account.

New screens

New lib modules

New Worker modules

New npm dependency

The bottom line

Match every feature.
Then out-build them.

Already ahead

Pricing intelligence, sell-signals, offline PWA, movers — Slabfy has none of these. We start with a lead, not a deficit.

Cheap to reach parity

Everything rides the existing single Worker + Supabase + Claude key. One new npm dep. Read-only eBay is free at our volume.

A wedge to grow

CSV import pulls users off CollX/Ludex. The storefront beats Slabfy's "coming soon." Their own article becomes our comparison-page template.

Next move: kick off the eBay developer application today (approval clock), then execute Phase 1 — fees math, tags, and CSV — which needs nothing but a table ALTER and immediately makes every profit number in the app real.

Cardboard · Slabfy-parity master plan · full technical detail in vivid-weaving-island.md