What I built after spending 5 minutes per item checking eBay in thrift stores

I'm a developer who thrift shops on weekends. For a while I was the person standing in the housewares aisle, phone out, searching eBay sold listings for a ceramic figurine I couldn't even name properly. It took forever. Half the time I'd give up and either buy it blind or leave it.

So I built a tool that does the lookup in the time it takes to take a photo. Here's what that actually required technically.

The core pipeline

The basic flow sounds simple: photo goes in, structured valuation comes out. In practice, getting this to run in under 4 seconds across a range of item categories required more iteration than I expected.

The first step is identification. I'm using a vision model (GPT-4o) to identify what the item is — not just "ceramic mug" but ideally something specific enough to search against sold listings: brand, approximate era, notable markings, condition. The prompt engineering here took a while to get right. Too vague and the search returns garbage. Too specific and you get zero results for anything that isn't a well-known collectible.

The second step is the sold listings lookup. This is where most of the latency risk lives. I'm querying eBay's Browse API for completed listings filtered to sold items, then pulling a sample of recent results to build a price range. The API is well-documented and the response times are acceptable, but "acceptable" and "fast" aren't the same thing. I run the identification and the search query in parallel where possible, using the first pass of the vision model output to kick off a search before the full identification is complete.

The third piece is platform recommendation. This is the least sophisticated part of the system right now. I'm using category signals from the identification step combined with price range to route toward eBay, Depop, Facebook Marketplace, or Poshmark. Clothing and vintage fashion skew toward Depop. High-value collectibles skew toward eBay. Bulky or local-pickup items skew toward Facebook. It's a heuristic, not a learned model. I'll probably revisit this once I have enough scan data to see where things actually sell.

What "category agnostic" costs you

The hardest part of building this wasn't any one technical piece. It was making the identification step reliable across completely different categories of items: vintage clothing, old electronics, pottery, board games, tools, sneakers.

A model that's good at identifying sneaker brands by colorway is not automatically good at reading hallmarks on silver flatware. The prompt structure I landed on asks the model to reason about the item in layers — what category it probably belongs to, what identifying features are visible, what searches would be likely to find comparable sold listings. That layered approach helped, but it also added tokens and latency. There's a tradeoff.

I also had to accept that the system will misidentify things. An unlabeled piece of pottery from a regional studio will come back with low confidence and a wide price range. That's honest — it's what eBay would return too if you searched vaguely. I'd rather surface that uncertainty than fake precision.

The latency problem

Four seconds sounds fast for a multi-step pipeline that involves a vision model call, an external API call, and a final synthesis step. It's achievable but not comfortable.

The two things that moved the needle most were parallelizing the eBay query with the tail end of the identification step, and caching category-level context so the synthesis prompt doesn't need to re-derive it from scratch. For items with high-confidence identification, I can sometimes shave another half-second by skipping a confirmation pass.

The mobile web experience matters here too. Most people will use this standing in a store on a cell connection. I'm not doing any client-side image processing — the photo goes up, the response comes back, done. Keeping the payload small and the server-side processing tight matters more than any clever frontend optimization.

What I didn't build

I spent time early on thinking about building a database of sold listings that I'd populate and maintain myself, so I could query it faster and have more control over the data. I scrapped that. eBay's sold listings data is current in a way I could never replicate at this stage, and building a scraping pipeline to maintain freshness would be a significant ongoing maintenance burden for marginal latency gains. External API dependency with rate limits is a better problem to have than stale data.

I also didn't build account-required signup for the first few scans. The friction of creating an account before someone can see if the thing works at all seemed like it would kill adoption before it started. The first five scans work without an account; after that you need to create one to keep going. This required a little extra work on the session/credit-tracking side but it was worth doing.

Where it lives now

The app is at thriftflipper.app. It's a web app, no download required, works on mobile. Ten free scans to start. I built it primarily for my own use case, but the feedback from other thrift shoppers has been useful for figuring out what the rough edges are.

The thing I didn't anticipate was how much the speed matters not just for convenience but for behavior change. When a lookup takes 30 seconds, you do it for items you're already confident about. When it takes 4 seconds, you check things you'd otherwise skip — which is where the interesting finds are.

If you're building anything in this space (real-time lookup, vision-to-search pipelines, pay-as-you-go credit systems on a small SaaS), happy to compare notes in the comments.