Elevate: Making Qwen the Brain of a Store That Runs Itself
How we built an AI that designs a storefront from a logo, runs it from live shopper behavior, and learns what sells — with the merchant as the human-in-the-loop. Built for the Global AI Hackathon with Qwen Cloud — Track 4: Autopilot Agent. Every small merchant hits the same wall. Building an online store is work. But running it — noticing what's selling, reacting to how shoppers behave, launching the right promo at the right moment, and knowing whether any of it actually worked — is a job nobody
How we built an AI that designs a storefront from a logo, runs it from live shopper behavior, and learns what sells — with the merchant as the human-in-the-loop.
Built for the Global AI Hackathon with Qwen Cloud — Track 4: Autopilot Agent.
The problem: running a store is a full-time job
Every small merchant hits the same wall. Building an online store is work. But running it — noticing what's selling, reacting to how shoppers behave, launching the right promo at the right moment, and knowing whether any of it actually worked — is a job nobody has time for.
The current wave of "AI for commerce" doesn't fix this. It bolts a chatbot onto a dashboard. You still ask. You still decide. You still do everything.
We wanted the opposite. Not an assistant you talk to — an agent that runs the store, where the owner just approves. Our one-line thesis, which shaped every decision:
The codebase is the body. Qwen is the brain.
Part 1 — Qwen builds the store (the easy part)
A merchant uploads a logo. That's the only input.
qwen-vl-max reads the image and returns structured brand DNA — dominant colors, mood, energy, industry cues. Then qwen-max turns that into a full brand: palette, typography, a brand voice, SVG icons, and — this is the fun part — a LayoutDSL: a JSON description of the store's structure. Which hero, which product grid, which card style, which navigation, in which order. A separate qwen-max call writes scoped, sanitized custom CSS on top.
The result: no two brands get the same store. Haree comes out light and editorial; Crest comes out dark and structured. Forty logos would give forty visually distinct storefronts. It isn't a template with the colors swapped — Qwen is the designer.
But a model that returns structure will hallucinate: an invalid variant name, zero sections, eight sections, a nav where a hero should be. So the renderer never trusts raw model output. Every LayoutDSL passes through three layers:
-
coerce_variant— type-aware; a hallucinated or cross-type variant falls back to that slot's default. -
normalize_dsl— structural guarantees the renderer alone trusts (at most one leading hero, at least one grid, 2–5 sections, no adjacent banners). -
fallback_dsl_from_token— a deterministic, brand-seeded blueprint (hashed from the store's name + mood + industry). If the Qwen call fails entirely, you still get a distinct, on-brand store.
The store-generation call never raises. A broken storefront is impossible by construction.
Part 1½ — Qwen stocks the store from a folder of photos
A brand shell is nice. An empty store is still empty. So we asked: how does inventory actually arrive for a real merchant? Not as a tidy spreadsheet — as a folder of phone photos. We got exactly that from a real seller: 98 pictures of branded footwear, names printed on nothing, prices nowhere.
So qwen-vl-max reads every photo. For each one it returns a structured draft — a sell-able product name from what it can see (the brand on the box, the type, the standout design), the colourways in the shot, a description in the store's own brand voice, a category, and a suggested price. One folder in; a full, categorised, copy-written catalogue out.
The interesting decision was pricing. The obvious feature — "web-search the usual price" — is a trap for resale goods: search returns designer MSRP ($400 for the Balenciaga slides) that has nothing to do with what an Offa reseller charges. A confidently-wrong price is worse than no price. So Qwen anchors every price to a merchant-set baseline and nudges by the premium-ness it can see, clamped so a hallucinated number can't reach the storefront — and it's explicit that it won't presume your margins. Knowing what not to guess is part of the intelligence.
And it stays honest about its eyes. It misread a "SUICOKE" strap label as "Suicide" once — a real brand, misread with full confidence. That's exactly why low-confidence reads are drafted inactive and handed back for a merchant's glance, instead of a silent wrong guess going live. Qwen does the 98× of tedious work; the human keeps the final say on the handful that matter.
And that review is a real step in the product, not a footnote. After the catalog lands, Qwen reviews its own import and surfaces only the products that need a human — a link whose image won't load, a missing price — as option cards to fix, hide, or keep. (The broken-image check runs in the merchant's own browser, so it catches exactly the dead links a customer would hit.)
Part 2 — Qwen runs the store (the actual point)
Building the store is the setup. The reason Elevate exists is what happens next.
Once the store is live, shopper events stream in over a WebSocket into Redis. A deterministic threshold watches for patterns — a cart-abandon surge, a velocity spike. When one crosses, Qwen runs a decision cycle.
And here's the part that makes it an agent, not an autocomplete: before it decides, it reads its own memory. Every past action for this store — what it tried, and whether it drove revenue — is fed back into the prompt. So Qwen's proposal is grounded in what actually worked for this specific shop.
It returns one action as an option card in the merchant's terminal: the play (a win-back offer, a flash sale, a layout shift), the trigger that caused it, the estimated revenue, a confidence score, and a brand-safety check. Then it stops.
That estimated-revenue number is one we deliberately took away from the model. Left to invent it, Qwen would answer the same trigger with $760, then $175, then $285 — confident, and meaningless. So the figure is computed from real signals instead: the size of the anomaly it actually detected, times the store's real average price, times a tunable rate. Same principle as the pricing: let Qwen decide what to do, but don't let it hallucinate a number a merchant will read as a promise.
The merchant taps Approve. The storefront morphs, live. This is the human-in-the-loop that Track 4 is all about: Qwen proposes, the merchant disposes. Nothing happens behind the owner's back.
And then the loop closes. When the action's promo resolves, a background outcome observer counts the orders attributed to it and writes a memory entry. The next decision reads it. Qwen genuinely gets smarter per store over time.
That loop isn't a mock — it reads back real money. In a test run on our demo store, a cart-abandon surge → an approved win-back offer → a shopper completing checkout under it attributed $74.70 to that one decision, live on the dashboard — total revenue moving $150.50 → $225.20, with the platform's 10% fee ($7.47 on that order) computed against it. That's the point of the whole loop: the number the agent drove, measured on the exact path a merchant would watch — not asserted.
Part 3 — Guardrails it can't override, and a store that won't break
An agent making business decisions needs brakes. Elevate has an immutable three-layer interceptor that neither the merchant nor Qwen can bypass:
- Layer 1 — Brand Guard: Qwen-authored rules, checked instantly on the client (zero latency) so a color change that breaks brand coherence warns in Qwen's own words.
- Layer 2 — Business Constraints: margin floors and discount ceilings, auto-clamped with a visible warning.
- Layer 3 — System Safety: anything that would sell below cost is hard-blocked. No exceptions.
These aren't theoretical brakes. In testing, a decision cycle proposed a 75% win-back discount; Layer 2 clamped it to that store's 40% ceiling before it could reach a customer — Qwen's number, the merchant's limit, with the reason shown. That's what makes the autopilot safe to hand real control: the agent can propose freely because the brakes are real and it can't touch them.
Robustness runs deeper than the interceptor, because a demo that fails silently kills the whole concept. Every Qwen call is hardened: bounded exponential-backoff retries on transient failures, immediate surfacing of permanent errors (no burning the clock retrying a 4xx), and a JSON extractor that recovers a valid object even when the model wraps it in prose. A Qwen outage degrades a product's description to plain copy instead of blocking the import. Redis is always best-effort with Postgres as the source of truth, so a cache blip never loses an order. Checkout decrements stock with a conditional update, so two shoppers can't buy the last unit.
The hardest bug lived in a seam
My favorite war story: the attribution dashboard — the closing beat of the whole pitch, "this action drove $X, your fee $Y" — was quietly reading $0.
Every layer worked in isolation. Unit tests were green. The bug only appeared when the entire loop ran with the action type the demo actually produces: a cart-abandon surge makes Qwen answer with a recovery offer, but only flash sales were registering an attributable promo. So the money-shot was empty on the exact path a judge would click. The fix made every revenue action attributable — and the lesson stuck: the happy path is not the interesting path. Some failures only exist in the seams between components.
Does it run in real time, and does it pencil out?
The fair question for any "autopilot": is it fast enough to matter, and is it viable per merchant? Both were design constraints, not afterthoughts. Building a full store — logo read, brand, icons, and a ~90-product catalog — costs on the order of a few cents in tokens, once, then it's cached forever; revisiting onboarding or the storefront never re-calls a model. After launch, Qwen doesn't run on a polling loop — it fires only when a real anomaly crosses a threshold, and it sends a telemetry diff, not the whole state. A decision cycle lands in seconds end-to-end. So cost scales with the events that actually matter, not with the hours a store is open — which is the only way "an agent per merchant" is economically sane at all.
Deployment
The backend runs on Alibaba Cloud ECS — FastAPI, PostgreSQL, and Redis as Docker containers on a single instance — with Alibaba OSS for logo storage (via the oss2 SDK) and Qwen Cloud for every model call. Two models, doing six-plus distinct jobs, with a closed learning loop between them.
What's next
Per-shopper personalization (the store adapting to each individual visitor), a self-extending config surface where Qwen proposes entirely new capabilities from recurring merchant requests, and cross-store learning so a brand-new shop benefits from what worked for similar ones.
So — did we beat the chatbot-on-a-dashboard we opened with? That pattern hands you a faster keyboard: you still ask, you still decide, you still do the work. Elevate inverts it. Qwen already built the store, stocked it, priced it, and watched it; the merchant's whole job shrinks to approving the exceptions. One makes you a better operator. The other gives you an operator. That's the line between AI in your store and AI running it.
The core is already here: an AI that builds a store, runs it, measures itself, and learns — with a human holding the approve button.
Elevate. The store that runs itself.
