Archit Art Gallery
End-to-end commerce and ops for an art gallery business — shop app, business panels, invoicing, Android tooling, and a Gemini-powered Amazon WALL_ART listing pipeline.
Commerce operating flow
From shop truth to invoice and marketplace listing — one business system.
- Catalog Shop product truth
- Invoice Business + Android docs
- Claim Listing worker lock
- Generate Gemini WALL_ART payload
- Validate Attribute checks
- Publish Marketplace ready
The challenge
An art gallery selling physical wall art across channels needs more than a storefront. Inventory, invoices/proforma, business users, and marketplace listings all have to stay consistent — especially when Amazon copy and attributes are tedious to produce at volume.
Legacy admin and invoice flows existed in pieces. Mobile staff needed reliable invoice creation; ops needed a shop stack that could grow into marketplace automation without breaking live sales.
Freeform “paste into ChatGPT” listing work created unverifiable copy, retries with no audit trail, and marketplace rejection risk when attributes drifted from product truth.
What we built
Across archit_2026 we delivered shop-app (Next.js), business/superadmin panels, invoice templates/APIs, and Android gallery tooling — including InvoiceMate-integrated invoice journeys.
On the growth side, we engineered an Amazon listing pipeline where Gemini generates WALL_ART listing payloads, tracked with pipeline status, attempts, and model metadata in MySQL.
Product, invoice, and listing rows share identity — so AI enrichment is an operable worker pattern (claim → generate → validate → publish), not a one-off script.
Platform architecture
Four surfaces, one product graph for the gallery business.
Shop app
Next.js customer storefront with product truth as the source of record.
Business panels
Superadmin and business consoles for users, inventory, and ops control.
Invoicing
InvoiceMate-aligned create → address → GST → lines → payment journeys.
Listing AI worker
Gemini pipeline with status, attempts, and auditable payload JSON.
System diagram
How shop data, invoices, and the Gemini worker share one commerce graph.
Customer
Ops
AI layer
AI never invents SKUs — it writes listing fields from existing product rows.
Design principles
Rules that kept commerce, invoicing, and AI listings operable together.
Product truth first
Listings and invoices reference shop rows — AI cannot invent the catalog.
Auditable AI
Every generation stores payload, model, and attempts for ops review.
Mobile invoice parity
Android journeys match documented API steps used on web.
Live-traffic releases
Deploys assume commerce is running; migrations must be safe.
How we approached it
We treated Archit as a multi-surface business system: customer-facing shop, internal business console, invoicing, and marketplace enrichment.
Invoice creation was mapped as a full journey — create document, resolve customer, billing/shipping addresses, GST categories, line items, finalize payment — mirrored in API docs for the Android app.
For Amazon, generation had to be queueable, retryable, and stored against the listing row so ops can see what the model produced and when.
Backups and seasonal dumps were respected as production reality; releases assumed live commerce traffic, not greenfield demos.
Schema helpers (ensure* migrations) let production self-heal pipeline columns when workers run — AI ops should not depend on a perfect manual migrate night.
Where AI enters — and where it must not
The Amazon listing pipeline is the clearest AI infusion: Gemini produces listing field payloads for WALL_ART SKUs, persisted as JSON with model name and timestamp.
Pipeline columns (status, attempts, last step, claimed_at) turn AI from a one-off script into an operable worker pattern.
Because gallery products have visual and material attributes, prompts are grounded in shop data rather than generic marketing fluff — reducing marketplace rejection risk.
Longer term, the same generation spine can extend to alternate marketplaces and multilingual listings without changing the product database.
Technical notes from production
Details that only show up once the season is real.
- Invoice journeys are documented as API contracts so Android and web stay synchronized on address, GST, and payment steps.
- Amazon pipeline state is first-class MySQL — status, attempts, claimed_at — so retries are operable, not tribal knowledge.
- Prompt inputs are grounded in product attributes to cut marketplace rejection from hallucinated materials or sizes.
- ensure* schema helpers keep worker deploys resilient when production columns drift.
Delivery & systems
Next.js shop-app, PHP business/superadmin surfaces, invoice HTML/API integration, and Android APK lineage for field invoicing.
SQL migrations for Amazon pipeline columns plus ensure* helpers so production can self-heal schema when workers run.
Release discipline assumed live traffic: dump-aware deploys and documented invoice API contracts for mobile.
Stack
Click a layer — each one maps to a real season responsibility.
Shop surface
Next.js
Customer-facing storefront that owns browseable product truth for the gallery.
Brand assets from the live product
Primary mark pulled from the Olympiad codebase — shown once, on the surface it was built for.
Outcomes
- Unified shop + business + invoice surfaces
- Android invoice journey integrated with InvoiceMate APIs
- Gemini Amazon WALL_ART listing pipeline with audit fields
- Production-safe migrations for AI worker state
- Product-grounded listing generation instead of freeform chat
