Vintage Value: AI-Assisted Resale Research and Consignment Inventory Handoff

A resale buyer standing in front of an unmarked piece has to answer three questions quickly and in sequence: what is this, what does it actually sell for, and does that leave a margin after fees. In practice those answers came from memory, phone searches across auction and marketplace sites, and mental arithmetic — done while other buyers were looking at the same shelf. The failure modes were asymmetric: passing on a good piece cost an opportunity, but overpaying on a misidentified piece tied up capital in inventory that had to be discounted later. The second problem was what happened after a purchase. Items bought in the field had to be re-photographed, re-described, priced, and keyed into the consignment system as a separate back-office task, days later, from notes. Research done at the point of purchase — the identification, the comparable sales, the intended price — was not carried forward, so it was effectively re-done or lost. Items also arrived in the store without photos, or with photos rejected for size, with no indication that anything had failed. A third constraint shaped the design: the store operates on consignment terms it controls. Split percentages, inventory type, and the acceptability of a recorded cost per item are store-side rules, not buyer preferences, and a tool that let a buyer type in the wrong values would produce records the store had to correct by hand.

Gulfturn Creative was responsible for the product end to end: requirements definition, data model, application build, AI integration, external marketplace and consignment integrations, multi-user security model, administrative diagnostics, and the public documentation set. The work was carried out iteratively against live use. Requirements were maintained as a living specification published inside the product, and every behavioural change was recorded in a user-facing change log stating the request and the outcome. Several requirements in the specification exist because a real failure was diagnosed against live data rather than anticipated in design — silently dropped photos, photo rotation lost during re-encoding, consignment records rejected for carrying a cost per item, and internal margin reasoning leaking into customer-facing store descriptions. Each was traced to a root cause, corrected, documented, and added to the specification.

Vintage Value implements a single linear workflow, deliberately short enough to complete while standing in a shop. Capture. The buyer photographs the item from several angles — mark, label, damage — and may optionally record the asking price and assign the item to a collection such as a specific estate sale. Photos are re-encoded on the device to JPEG at two sizes: a store-quality copy at 1600px used for display and for the consignment system, and a smaller 900px copy used for analysis. EXIF orientation is applied to the pixels before writing, so a photo never rotates during processing. Identification. The smaller copy is sent for vision analysis, which returns ranked candidate identifications with confidence scores, category, estimated era, maker or brand where inferable, and a short history. The buyer selects one candidate as the working identification, or adds a detail such as a maker mark and re-runs the analysis. Pricing. Comparable listings and sales are retrieved from eBay and Etsy for the selected identification, with AI market synthesis used only as a fallback when live comparables are thin. The result is a low / mid / high estimate band, an explicit statement of the basis used (sold comparables, market pricing, mixed, or limited data), and a confidence label. The buyer's commission percentage and flat fees — defaulted from their profile, editable per item — are applied to produce net profit at each point in the band, and a strong buy / buy / caution / pass recommendation with a stated reason. Each calculation is stored as an immutable snapshot so price movement is visible over time. Handoff. Items the buyer actually purchased are selected and sent to The Wooden Nickel's ConsignCloud account. Title, category, resale price, purchase price, and photos are mapped automatically, and each item is assigned a sequential SKU in the form Vv000001 so store staff can identify at a glance which records originated here.

AI is used at two points, both advisory. Identification. A vision model receives the buyer's own photographs of the item and returns ranked candidate identifications with confidence scores, category, estimated era, maker or brand where inferable, and short historical context. It receives only the photos and any free-text detail the buyer adds; it does not see pricing, cost, or the buyer's margin thresholds. Pricing synthesis. The preferred pricing input is live comparable listings and sales retrieved from eBay and Etsy. AI market synthesis is a fallback used when live comparables are insufficient, and the resulting estimate always declares its basis — sold comparables, market pricing, mixed estimate, or limited data — alongside a confidence label, so the buyer can see how much of the number rests on retrieved evidence. Limits, stated plainly. Identification of unmarked, heavily repaired, reproduction, or regionally obscure pieces is where confidence is lowest, and a low confidence label should be read as a prompt to look for a mark rather than as a valuation. Comparable coverage is uneven by category: common marketplace categories are well covered, while thin categories fall back to synthesis and carry a wider band. No AI output sets a price, records a purchase, or writes to the store; the buy / caution / pass recommendation is arithmetic on the estimate band and the buyer's own fee inputs, not a model judgement.

The buyer is the decision-maker at every consequential point. Identification requires explicit selection. Candidates are proposed ranked, but none becomes the item's working identification until the buyer chooses it, and the buyer can supply an additional detail and force a re-run instead of accepting the list. Purchase and pricing are human. Acquisition cost, resale price, commission, and flat fees are entered by the buyer. The recommendation badge is advisory and carries a written reason; nothing in the system prevents buying against a pass or passing on a strong buy. Store writes are explicitly triggered. Nothing reaches ConsignCloud automatically. The buyer selects the items to send and confirms the action, already-sent items cannot be sent again, and an item missing a resale price is refused before the call with an explanation rather than failing opaquely. Exceptions surface rather than silently resolve. Photo failures produce an on-screen warning naming the reason and are written to the integration log. A missing store link blocks the send and records the block. Store-side commercial terms — the consignment split — are read from the store and shown read-only, so a buyer cannot introduce terms the store did not set. Administrative review. Admin accounts can filter the integration log by outcome and expand any entry to the exact payload sent, which is how mapping defects have in practice been found and corrected.

The application is a React front end on the Base44 platform, with server-side backend functions handling every external call. Data model. Records are modelled as owner-scoped entities: items, item images, collections, identification results, price comparables, pricing snapshots, item histories, user profiles, consent audit records, and integration logs. Pricing snapshots and identification results are append-only, so the reasoning behind a past decision remains inspectable. External integrations. Four backend functions isolate outbound traffic: marketplace comparable retrieval from eBay and from Etsy, a pricing research function that assembles comparables into an estimate, and a ConsignCloud bridge handling account matching, item creation, and photo upload. Credentials for all four are held as server-side secrets and are never present in the browser. Consignment integration specifics. ConsignCloud accepts photos only as base64 within a request ceiling of roughly 2MB, which drove the on-device downscaling; if a store-sized photo is still rejected, the smaller research copy is attempted automatically. Consignment split is read from the consignor's existing store records rather than entered by the buyer, and is displayed read-only. Cost per item is omitted on consignment inventory, which ConsignCloud rejects, and the purchase price is written to a store custom field that accepts a value on every inventory type. An item with no resale price is held back before the call is made, because the store requires a tag price. Diagnostics. Every consignment call writes an integration log entry — action, user, item, outcome, message, HTTP status, duration, and the exact payload sent — classified as success, failure, or blocked by a precondition. Logging runs under the service role and cannot throw, so a logging fault cannot break the operation it is recording.

Tenant isolation. Every owned record — items, images, collections, profiles, identifications, comparables, pricing snapshots — carries an owner recorded at creation and is scoped to that owner by row-level security enforced server-side, not by front-end filtering. The application supports unlimited accounts, and each account sees only its own inventory, pricing, and settings. Credential handling. All external API keys are server-side secrets accessed only inside backend functions; no key is present in delivered browser code. Consignment account binding. A user can only link the consignor account whose email address matches their own sign-in email, and the match is enforced on the server. Consignor accounts cannot be browsed or selected. If no consignor record uses the signed-in email, the application explains the mismatch and directs the user to the store rather than offering an alternative account. Separation of internal and customer-facing content. Only the user's own notes are sent as the store description. Internal research output — the buy / caution / pass rationale and any estimated margin or net profit figure — is never transmitted to the store. This requirement exists because margin text was found in live store records and was corrected. Consent. Contribution of anonymised item data to aggregate pricing intelligence, and reuse of photographs, are separately opt-in, versioned, and recorded as consent audit entries. Aggregate cross-user data is visible only to admin accounts and only where the contributor consented. Access control on diagnostics. Integration logs are readable, writable, and deletable only by admin accounts, enforced by row-level security. Authentication. Email and password or Google sign-in, with one-time-code verification at registration.

Demonstrated in production use rather than measured against a baseline. Quantified operational outcomes are not disclosed at the client's discretion, and no before-and-after measurement was instrumented, so the following are capabilities observed working on live data rather than performance claims. The end-to-end path is in service: an unidentified item photographed in the field is identified, priced against retrieved marketplace comparables, decided on, and — if purchased — created in the live ConsignCloud account with photos attached, a resale price, a purchase price, and a Vintage Value SKU, without separate back-office re-entry. Diagnosability changed materially. Before the integration log existed, a failed send was indistinguishable from a successful one; afterwards, four distinct defect classes were identified from live log entries and corrected — sends blocked by an unlinked store account, consignment records rejected for carrying a cost per item, items rejected for a missing tag price, and photos silently dropped for exceeding the store's encoded request ceiling. Storage and transfer were reduced by on-device re-encoding to JPEG at two sizes, with a one-pass cleanup available for photographs captured before that behaviour existed. The reduction is directional and self-reported by the cleanup tool, not independently audited. Provenance in the store is now unambiguous: sequential Vv-prefixed SKUs let store staff identify the origin of any record on sight.

The pattern generalises beyond antiques resale: a field worker must make an irreversible, money-committing judgement about a physical object, quickly, with incomplete information, and the result must land in a system of record without re-entry. Three elements transfer directly. First, AI as an advisory layer over retrieved evidence — the model proposes, external data substantiates, the estimate declares its own basis and confidence, and a human commits. Second, integration against a system of record whose rules are not yours to change: commercial terms read from the authoritative system rather than entered locally, payloads shaped to constraints the external system enforces, and preconditions checked before the call so a user sees a plain-language reason instead of an opaque error. Third, diagnosability as a delivery requirement rather than an afterthought — logging every external call with its payload and outcome, classified so that a blocked precondition is not confused with a remote failure, and restricted to administrators. The same shape applies to field inspection and condition assessment, asset intake and disposition, appraisal support, and any workflow where a mobile capture step must reconcile with an authoritative back-office system. The multi-tenant isolation model — server-enforced ownership on every record, with identity-bound linking to external accounts — is the baseline for delivering such a workflow to many independent operators from one deployment.