Skip to content
Gulfturn Creative
← Back to Work

Client Delivery

/ Commercial

POS-Synchronized Commerce Platform for a Multi-Vendor Antique Mall

A public storefront, staff back office, and analytics layer built on top of a consignment POS. Inventory, sales, and fulfillment stay reconciled through webhooks and scheduled jobs, while an AI enrichment pipeline turns sparse POS records into listable products under human-controlled thresholds.

Domain
Retail commerce and inventory operations
Client
The Wooden Nickel

Capabilities

Systems integrationAPI integration and data reconciliationApplied AI and LLM pipelinesE-commerce and paymentsWorkflow automationData modeling and analyticsWeb application engineeringAgent-accessible interfacesApplied AIWorkflow ModernizationDigital PlatformsAgentic Web and AEOCloud and Integration

Operating Conditions

The Wooden Nickel is a multi-vendor antique mall in Dade City, Florida. Its system of record is ConsignCloud, a consignment POS holding roughly 1,100 and counting one-of-a-kind items across dozens of consignor accounts. Selling that inventory online created three structural problems. First, listing quality. POS records are entered quickly at intake: a title, a price, sometimes a category, often no description and no photo at the moment of creation. That is sufficient for a price tag and insufficient for a product page, a search result, or a Google Shopping feed. Second, double-sale risk. Every item is unique, so the same piece can be sold at the register and in the cart within the same minute. A conventional nightly inventory sync leaves a window in which the website can take money for an item that no longer exists. Third, operational load. Any process requiring a staff member to keep a browser tab open, re-key an online sale into the POS, or manually reconcile vendor splits does not survive contact with a working retail floor. The platform also had to serve two audiences from one dataset: customers browsing and buying, and the owner reconciling daily register close, vendor payouts, and category performance.

Gulfturn Creative’s Role

Gulfturn Creative was the sole design and engineering party for the platform: discovery, data modeling, integration work, AI pipeline design, storefront and admin UI, scheduled automation, and the operating documentation staff work from. Scope included integration with the client-owned ConsignCloud POS, Square payment account, EasyPost shipping account, Google Places listing, and Google Merchant Center account. Gulfturn did not administer those third-party accounts; credentials remain client-held and are consumed as configured secrets. Delivery has been iterative and evidence-led. Integration behavior was verified against the live POS rather than assumed from documentation, and several documented behaviors were found to be wrong in ways that materially affected inventory correctness. Those findings, their root causes, and their fixes are recorded in an in-app change log and requirements document that ship as part of the system.

What Was Built

The platform is a single application with three surfaces over one dataset. Storefront. Category-based browsing over sixteen parent categories with sub-category rails, per-category and store-wide search, brand filters, sorting, pagination, and URL-persisted list state so a filtered view is shareable and survives navigating into a product and back. Product pages carry AI-derived specifications and a gallery of source and generated imagery. Guest checkout supports shipping and in-store pickup, multi-unit quantities, server-side pricing, and a two-step review before payment. Back office. Product, vendor, journal, event, and lead management; an order queue with packing slips, USPS label purchase, tracking, and shipping-overage refunds; a sync console with live progress and recovery controls; an enrichment queue with per-item audit logs; and a staff training mode that exercises the full order lifecycle against a hidden practice item and a simulated payment that never touches real inventory. Analytics. A daily register-close dashboard reproducing the owner’s existing spreadsheet, plus per-line-item trend analysis by vendor, category, era, price band, and brand sell-through. Automation carries the operational load. Scheduled jobs handle background catalog import, enrichment, status reconciliation, deletion sweeps, tracking sync, review refresh, and two daily digest emails.

AI and Human Roles

AI is applied to one bounded problem: converting a sparse POS record into a listable product. It is not used for pricing, availability, order handling, payment, refunds, or financial reporting. Inputs are evidence the store already owns: the item photograph, the consignor-entered title, and the POS fields for brand, category, description, and condition. Source-data priority is explicit — where the POS holds a value, that value wins and AI does not overwrite it. AI fills only what the POS lacks. A vision model extracts era, dominant color, estimated weight, and approximate dimensions, and returns a self-reported confidence score. Description handling is deterministic by word count: a description of ten or more words is used verbatim; three to nine words are treated as keyword anchors and synthesized into prose; fewer than three triggers generation. Generated copy is constrained to the material named in the title and prohibited from asserting flaws, damage, or defects. Two supporting images — a styled environment shot and a specification card — are generated under instructions to reproduce the reference item without altering its form, color, or finish. Limits are known and documented. Confidence is model-reported, not validated ground truth. Extracted weight is an estimate and drives a shipping quote, so an underestimate costs the store postage rather than the customer. The provider safety filter blocks generation for some subject matter; those items publish with enriched text and their original photograph only. Enrichment never sets stock levels or price, which are mirrored from the POS. A separate large-language-model pass was used once for brand recovery, instructed to return a brand only when explicitly present in the title and otherwise to abstain.

Human Controls

Every AI output passes a gate the client controls. A master enrichment toggle stops all AI work. An admin-set confidence threshold decides publication: at or above it an item publishes, below it the item is held as needs-review and waits for a person to approve, re-run, or discard it. Qualifying rules — price threshold and which fields are mandatory — are admin settings, not code. Every item carries a step-by-step ingest log, so a rejection or failure is explained rather than silent. Enriched values remain editable in the product editor, generated assets can be removed or regenerated individually, and a type-ahead constrains category entry to established values so a piece cannot be filed somewhere customers never browse. Money and inventory are human-gated by design. Refunds are never automatic: staff enter an amount and confirm, and the amount is capped server-side at the shipping actually collected. Shipping labels are purchased explicitly, with a warning when any item lacks a measured weight. Order status advances by staff action. When an automatic POS write fails, the order is flagged for manual ring-up rather than silently reconciled. Staff are trained against a hidden practice item and a simulated payment that marks an order paid without contacting the payment processor, touching stock, or writing to the POS. Two daily digest emails give the owner an independent view of what the automation did, including estimated AI spend and any stalled queue.

Architecture and Integrations

Front end is React with a shared design-token system, code-split routes, and client-side caching. Persistence uses schema-defined entities with row-level security: public read on storefront data, admin-only read on financial and lead data, and public create limited to checkout and public forms. Two additional pages are locked to a single authorized account behind an email guard. Integrations, all server-side in isolated backend functions with secrets held outside the client: ConsignCloud POS (REST). Item, account, sale, line-item, and register-report reads; sale creation for online orders. Three webhook subscriptions (item.created, item.updated, item.sold) POST to a single structural-validation handler, since the vendor supports neither signing nor secret tokens. Handlers return in one to two seconds and defer all slow work, because the vendor deletes a subscription after repeated slow or failed deliveries. Square (OAuth connector). Hosted payment links, payment verification, and partial refunds. No card data reaches the application. EasyPost (REST). Live USPS rate quotes at checkout, label purchase, and HMAC-verified tracker webhooks, with a polling job as a safety net. Google Places API. Daily review refresh into a cached entity. Google Merchant Center. Two generated feeds — a product RSS feed and a local in-store inventory feed — served from the live catalog under identical eligibility rules so ids and prices agree. WebMCP. Five tools registered on navigator.modelContext for browser-resident AI agents: browse_showcase (filterable by era and status, returning title, price, era, condition, brand, color, weight, and description), browse_vendors, browse_events, read_journal, and subscribe_newsletter. Registration is capability-detected and no-ops silently in browsers without support. Durable multi-step processes run as scheduled workflows invoking backend functions, with cursors and counters persisted so a run resumes rather than restarts.

Security, Compliance and Accessibility

Card data never enters the application. Payment collection and card verification occur on the processor’s hosted page; the platform stores only a payment identifier and the customer-supplied billing address, which is retained for the store’s records. Refunds are issued against the original payment through the processor API. All third-party credentials are server-side secrets consumed only by backend functions and never exposed to the browser. Row-level security restricts financial, order, and lead data to administrators; storefront data is public-read; public create is limited to checkout and public forms. Inbound webhooks are authenticated per provider capability. The shipping provider’s events are verified by HMAC-SHA256 and rejected when unsigned or mis-signed. The POS supports no signing mechanism, so its events are validated structurally and treated as untrusted triggers: the handler re-reads the authoritative record from the POS API rather than trusting payload contents. Two hardening findings were remediated during delivery. An enrichment-trigger endpoint reachable without authentication allowed a third party to force paid AI work; it now requires an internal secret or an admin session. A server-rendering endpoint reflected an unescaped query parameter; input and error output are now escaped and errors served as plain text. Operational safeguards include capped batch sizes, bounded concurrency with retry and backoff against provider rate limits, idempotent upserts keyed on provider identifiers, and server-side recomputation of every price and total at checkout.

Results

Demonstrated
Outcomes below are demonstrated system behaviors observed in the live environment. Commercial metrics such as revenue effect are not disclosed. Online orders reconcile without re-keying. A paid order marks its items sold on the site and writes a finalized sale into the POS, so vendor splits settle automatically and the register cannot resell the piece. Failures are flagged for manual ring-up rather than lost. Double-sale exposure is closed at the point of payment. Before a payment link is created, the platform queries the POS for live availability of each piece and refuses checkout for anything sold at the register in the interim. Inventory correctness is defended in layers: a real-time sold webhook, a fifteen-minute reconciliation pass, and a six-hour deletion sweep that inspects each available item individually — the only way to detect a POS deletion, since deleted items are excluded from the list endpoint yet still report as active. A verified sweep cleared a deleted item and checked 539 remaining items with zero lookup errors. Time from intake to storefront is roughly five minutes from the moment a photograph is attached, without a human step, once an item passes the qualifying rules. Three integration defects with silent data consequences were found by testing against the live API and corrected: an active-unit count read as a boolean flag, which had been rejecting every multi-unit item; a description field read under the wrong key; and record caps that were hiding the oldest products from public browsing and reconciliation.

Transferable Practice

The pattern generalizes to any organization whose authoritative record lives in a system it does not control and cannot replace. The engineering problem is not building a storefront; it is maintaining agreement between two systems whose failure modes are undocumented. Three transferable practices came out of this delivery. Verify integration behavior against the live system rather than its documentation — three field-level defects here were invisible in the docs and silently corrupted inventory state. Keep webhook handlers fast and defer slow work to scheduled jobs, because providers retire subscriptions that respond slowly and rarely announce it. Treat any single reconciliation mechanism as insufficient and layer real-time events, periodic reconciliation, and direct-lookup sweeps according to what each can actually observe. The AI approach is equally transferable: apply generative models to a narrow, evidence-anchored enrichment task; give existing authoritative data priority over model output; gate publication on an adjustable confidence threshold; and keep money, stock, and status changes under explicit human action.

Capabilities Demonstrated

  • Bi-directional POS integration with webhook ingest and scheduled reconciliation
  • Layered inventory-correctness controls: real-time events, periodic reconciliation, direct-lookup deletion sweep
  • Hosted-checkout payment integration with server-side pricing and pre-charge availability verification
  • Automatic point-of-sale write-back of online orders, including vendor settlement splits
  • Live carrier rate quoting, label purchase, tracking sync, and human-gated overage refunds
  • Vision-model enrichment with source-data priority, deterministic description rules, and confidence gating
  • Constrained generative imagery with fidelity and layout guardrails
  • Google Merchant Center product and local-inventory feed generation from a live catalog
  • WebMCP tool registration for browser-resident AI agents with graceful capability detection
  • Durable scheduled workflows with persisted cursors, progress telemetry, and manual recovery controls
  • Row-level security segmentation across public, customer, and administrative data
  • Financial reporting reconciled to point-of-sale register-close data
  • Operational documentation and a simulated-payment staff training mode

Technologies

ReactTailwind CSSBase44 platform (entities, backend functions, workflows, row-level security)ConsignCloud POS REST API and webhooksSquare payments and refunds (OAuth connector)EasyPost USPS rating, labels, and tracking webhooksGoogle Places API (New)Google Merchant Center product and local inventory feedsWebMCP (navigator.modelContext)Vision and text large language models for catalog enrichmentGenerative image models for supporting product imageryGoogle Tag Manager with single-page-app virtual pageviews

Disclosure

AI is used only to enrich catalog records: a vision model extracts era, color, estimated weight, and dimensions from the item photograph, and a language model writes or synthesizes descriptions when the point-of-sale record lacks one. Point-of-sale data always takes priority over model output. Model confidence is self-reported and gates publication against an admin-set threshold; below-threshold items are held for human approval. AI does not set prices, availability, or stock levels and takes no part in payments, refunds, or financial reporting. Estimated weights drive shipping quotes and are reviewed by staff before a label is purchased. All enriched values remain editable, and every enrichment run is logged for audit.

Next Step

Have a system of record you cannot replace? We build the platform around it.

Tell us about your mission or workflow and we'll show you how we'd approach it.

Discuss a Platform