WorkCollectibles Claims & Sales Platform

Back office for chat-group commerce

Collectibles Claims & Sales Platform

Automates the brutal seller side of messaging-group 'claim sales' — live catalogue, timestamp-fair claims, invoices — without changing how buyers buy.

Status
Live
Category
Business system
Year
2026
Role
Built as a product and run against a real seller's sales.
Recreated interfaceIllustrative composition with representative demo data — not a customer screenshot.

The problem

Collectibles sellers run claim sales in messaging groups: post an item, first reply of 'mine' wins it. Buyers love it. The seller's side is brutal — claims, backups, multi-quantity lots, running totals and per-buyer invoices, all tracked by hand at speed while the sale is live.

Constraints

  • Buyers change nothing — the group-chat ritual is the whole point, so the system had to be invisible to them
  • Claims arrive in bursts; resolution must stay timestamp-fair under race conditions
  • Payments are local bank transfers, not cards — the flow has to be reconciliation-friendly
  • It runs unattended during a live sale, because the seller is busy selling

The approach

Automate the seller and leave the buyer experience completely untouched. A linked-device bridge reads claims straight from the real group and confirms them with reactions; a realtime catalogue mirrors live claimed/available state; and an AI vision scanner turns a pile of item photos into priced, listed lots.

What was built

  • Messaging-group bridge that reads claims and confirms with reactions — buyers never change how they buy
  • Realtime catalogue with live claimed/available badges and buyer-total lookup
  • First-come-by-timestamp resolution, backup claims and multi-quantity stock handling
  • Sale close that posts a tagged group summary plus individual DM invoices
  • AI vision scanner: reads each item, cross-references a collector database, translates foreign-language cards, prices lots
  • Password-protected admin dashboard; security-definer RPCs behind a hashed key; rate-limited AI endpoint; bank-transfer payment flow

Contribution

  • Product Strategy
  • Systems Architecture
  • AI Workflow Design
  • Frontend Development
  • Deployment

Built with Supabase · Postgres · Edge Functions · Realtime · Claude vision · Cloudflare Pages · Netlify

Technical decisions

Automate the seller, not the buyer

The obvious build was a slick new storefront forcing everyone to migrate. The valuable build was invisible: same group, same ritual, zero buyer friction — and the entire back office gone.

Timestamps are the referee

Contested claims are resolved by message timestamp in the database, not by whoever the seller saw first — fairness became a schema property instead of a judgment call.

Evidence

The live claim-sale storefront resting between sales, showing catalogue tabs and an honest empty state
Actual interfaceThe live storefront between sales — the realtime catalogue idles honestly when nothing is on. Seller branding cropped.
Simplified architectureSimplified architecture — a device bridge reads the real group, Postgres resolves claims timestamp-fair, and the storefront mirrors state in realtime.

Outcome

  • Shipped on a custom domain and used for a real seller's claim sales
  • The seller's manual back office — claims, totals, invoices — runs itself during a live sale
  • The buyer side needed zero migration: same group, same ritual

Current status

LiveLive — shipped on a custom domain and run against a real seller's claim sales; the messaging bridge and invoice flow operate end to end.

Lessons

The best automation target is the person drowning in tabs, not the person having fun.

Next stage

Multi-seller onboarding is the open question — it gets built when a second seller asks, not on spec.

Contact

Have a business problem that needs a better system?

A website that doesn't convert, a workflow held together by spreadsheets, an idea that needs a working pilot — tell me about it. I'll give you an honest read, including when you don't need custom software.