POSTA

Listing collectibles involves the same work, over and over.

Existing tools automate listing. Collectibles add another layer.

I looked at existing listing and cross-posting tools to understand what sellers could already automate. Most handled common tasks. Authenticated collectibles introduced more specific requirements: certification numbers, grading information, marketplace taxonomy, and category-dependent item specifics.

Not every part of the workflow should be automated equally.

I ranked which decisions were worth automating, which needed transparency, and which had to stay with the seller.

From product photos to a reviewable listing.

Upload a batch of product photos — fronts, backs, slabs, cert cards, all mixed together. POSTA groups them by item so you don't have to sort anything before you start.

7 mixed photos might become 3 grouped items. Claude makes that call so the seller doesn't have to.

Claude interprets the grouped images — reads the player name, cert number, authentication company, grade, and condition — and turns those details into a structured eBay listing the seller can review and correct.

Opus was chosen over cheaper models on purpose. On a $500 card, description quality shows up in the sale price.

Each listing card keeps a direct link to Terapeak, eBay's sold-comps tool, so the seller can check what comparable items have actually sold for before setting a price.

Pricing stays with the seller. POSTA never suggests a price — that decision requires market knowledge the system doesn't have.

Pricing research screenshot

Review generated listings, edit anything that needs correction, set the price, and prepare completed listing data for the eBay workflow. Approve individually or in bulk.

A card layout gives each item enough visual weight to make that review feel deliberate rather than like scanning rows in a spreadsheet.

Explore the workflow.

Click through to see how a seller moves from uploaded photos to reviewing an AI-generated listing. Some backend functionality is still in development.

Building the interface exposed the system underneath it.

I started POSTA as a product design project. Once I began building, decisions that looked simple in the interface started depending on authentication, marketplace APIs, database structure, and the format of AI-generated output.

What POSTA is built on.

Identifying the item wasn't enough.

Claude could recognize an item and generate plausible listing information, but eBay doesn't accept a plausible category. A listing has to resolve to a valid leaf category, and that category determines everything else the marketplace expects.

That turned category selection from a classification problem into a systems problem. I began building a set of cooperating resolvers with seller-specific category memory in front of them.

The architecture now constrains AI decisions with marketplace data instead of assuming that a reasonable AI answer is necessarily a valid marketplace answer.

How it all connects.

A two-phase flow — generate listings from photos, then publish to eBay. The publish side depends on the category resolver that is still in development.

Building revised three assumptions I made while designing.

Building POSTA changed how I design.

I knew how to design a workflow. I knew how to map an existing process, identify repetitive work, and design an experience that reduced unnecessary decisions. That part came naturally.

What I didn't know was how to design a system. Building POSTA pushed me into APIs, OAuth, authentication, database architecture, marketplace taxonomy, and the relationship between AI-generated information and what an external system will actually accept.

It changed how I start. I used to treat implementation as something that followed design. POSTA taught me to test technical assumptions much earlier, especially when an experience depends on external APIs or system rules that aren't visible from the interface.