SnapSell

Inspiration

We've all been there: standing at a garage sale, holding something that might be worth $20 or might be worth $200, with no good way to know. You pull up eBay, search around for a few minutes, find listings that are all over the place, and end up either passing on something valuable or overpaying for junk. And that's just the buying side. If you actually want to sell something, you're looking at 30-60 minutes of research, writing, category-hunting, and form-filling before a single listing goes live, assuming eBay doesn't silently reject it for a missing field you didn't know was required.

We wanted to fix that. Not with a better spreadsheet or a smarter search, but with something that actually does the work for you.

What it does

SnapSell is an AI-powered resale assistant. You photograph an item, and within seconds you get a full appraisal: low, mean, and high price estimates pulled from real comparable sales, a confidence score, a volume count, and a plain-English recommendation: buy, haggle, pass, or not enough info. If you decide to buy or list, one tap posts directly to eBay with the title, description, category, and item specifics already filled in. The app tracks your full portfolio, inventory, listed, sold, portfolio value, realized revenue, and flags listings that have gone stale to help you reprice before they die.

How we built it

The frontend is React 19 with TypeScript, Redux Toolkit, and React Router. The backend is a Flask app with JWT auth, PostgreSQL for persistence, and a dedicated Node.js price agent microservice that orchestrates research across a handful of sites, crafting comparable sales, discovery, and valuation. For AI, we used Gemini 2.5 Pro for multimodal item identification and appraisal, and Gemini 2.5 Flash for resolving eBay item specifics and category selection. Listing goes through eBay's Trading API, with image hosting via eBay's EPS service and price revisions through the revise endpoint.

The eBay API problem (and how we solved it)

eBay's API has a reputation in developer circles, and it earned it. There are 17+ separate APIs with inconsistent formats, a sandbox environment that frequently breaks, and, most painfully, required listing fields that silently change depending on which of eBay's thousands of product categories you're listing in. You don't find out a field is missing until your listing gets rejected mid-submission.

Our solution was a concurrent preflight system. The moment an item is saved, we fire off three things in parallel: Gemini resolves the optimal eBay category, a VerifyAddItem-style call probes which item specifics are required for that category, and the image uploads to eBay's hosting service. Gemini Flash then drafts values for every required field: Brand, Material, Size, Color, whatever eBay needs, using the item data we already have. By the time the user taps "List," every required field is already resolved, the image is hosted, and the listing posts cleanly on the first try. This alone saves the ~30-60 minutes research and manual listing takes.

Challenges

The eBay API was the biggest one. The documentation is fragmented across multiple portals, examples are often wrong or outdated, and error messages frequently point you in the wrong direction. We spent a meaningful chunk of the hackathon just learning what calls needed to be made in what order, which is exactly what inspired the concurrent preflight approach. Once we had that working, the rest of the listing flow came together fast.

Getting Gemini to output consistent, structured JSON was the other main challenge. Multimodal models can be expressive when you want them to be precise. We ended up giving access to tool use, being very explicit in our prompting, specifying schema, enumerating valid values for fields like condition, and using a needs_review flag for cases where the model's confidence was genuinely low rather than letting it hallucinate a confident answer.

What we learned

Concurrency isn't just a performance optimization, sometimes it's an architectural necessity. Running sequential API calls to eBay would have made the listing flow feel broken. Parallelizing them made it feel instant.

We also learned a lot about building for uncertainty. Resale is inherently fuzzy, item conditions are subjective, comp data is noisy, and market prices shift. The right design response isn't to hide that uncertainty; it's to surface it honestly. That's why the appraisal shows confidence percentages and comp volume, not just a single price. Users make better decisions when they understand what the AI actually knows.

What's next

Dynamic repricing is already in the backend — the staleness detection and eBay revise endpoint integration are live. The next step is surfacing that more prominently in the UI and letting users set repricing rules rather than just getting flagged. We'd also like to expand beyond eBay to other marketplaces, and explore a mobile-native version where the camera integration is tighter. Cleaner auction support could also be a nice next step!