Elevate — Devpost project details

Tagline: The store that runs itself. Qwen builds it from your logo, proposes every move from live shopper behavior, and learns from what you approve, and what actually sells. You just approve.

Track: Autopilot Agent (Track 4)


Inspiration

A few years ago, watching business owners pour everything into their work — and still somehow miss the thing that matters most: being present in their own store.

Not physically. Strategically.

Products get added. Orders get fulfilled. But the store itself just sits there, static, while customers come and go unnoticed. No one's watching the patterns. No one's responding to the signals. The owner is too busy running the business to actually read it.

That gap is what Elevate was built to close.

What it does

Elevate begins with a single upload: your logo. From that, Qwen builds your entire storefront — its palette, typography, layout personality, and every product description. No two brands get the same store.

Then it does the part that actually matters. It runs alongside your storefront in real time, watching what your customers do — what they browse, what they hesitate on, what they abandon — and proactively checking pricing, scarcity, and catalog health on its own schedule. It translates those signals into decisions your business can act on immediately.

Not suggestions in a dashboard. Not a report you read tomorrow. Actions: a flash sale, a win-back offer, a layout shift — proposed as clear option cards, and executed the moment you approve them. And every action is measured against real orders, so you always know what the AI actually drove.

The store stops being a static catalogue and starts working with you. You stay in control. Qwen handles the clarity.

How we built it

We built Elevate on one conviction: the code is the body, but Qwen is the brain.

The backend is FastAPI with a WebSocket pipeline carrying every live signal — no polling anywhere. PostgreSQL holds the source of truth; Redis is the fast operational layer. The frontend is Next.js, and it renders each store from a LayoutDSL — a JSON blueprint of structure that Qwen composes uniquely per brand.

Qwen Cloud does the thinking, across two models and seven distinct jobs: qwen-vl-max reads the logo and every product photo; qwen-max generates the brand, composes the layout, writes the scoped CSS, writes every product description in one batched call, and even translates a merchant's plain-language edits into real design changes. The decision cycle itself isn't one prompt with every tool — it's a swarm of four role-scoped specialists (Pricing Strategist, Sales Rep, Store Curator, Inventory Overseer), each limited to its own tools and able to escalate to another when the fix is outside its lane.

The piece we're proudest of is the loop that closes: when an action resolves, an outcome observer measures the orders it drove, writes a memory entry, and the next decision reads it back — plus a quantified, per-role stance that measurably shifts the next proposal toward what this merchant keeps (and it's shown on the Decision Trace page, so the learning is visible, not asserted). Qwen doesn't just act — it remembers, per store, and gets sharper over time.

And because an AI making business decisions needs brakes, everything passes through a safety stack Qwen can't override: a Layer-0 structural guard that makes an illegal move (a negative or over-100% discount, a zero price, a phantom target) simply unrepresentable, then an immutable three-layer interceptor — brand coherence, business constraints like margin floors and discount ceilings, and hard system-safety limits like never selling below cost. Every lifecycle event is written to a tamper-evident, hash-chained decision ledger, and a small, already-safe pricing move can earn bounded auto-apply — trust that only ever removes the gate, never widens the range, and resets on a single dismissal.

It's deployed on Alibaba Cloud: the backend, Postgres, and Redis running in containers on ECS, with Alibaba OSS for asset storage and Qwen Cloud for every model call.

Challenges we ran into

The interesting failures never live on the happy path.

Our sharpest bug was invisible in every unit test: an order that stacked two promos — a product-level flash sale plus an order-level win-back offer, exactly what a real cart-abandon-then-purchase looks like — was silently dropped from attribution entirely. The matching logic checked a single promo id against a comma-joined list, found no exact match, and the revenue landed but was never credited to either action — the learning loop read it as no conversion at all. Every layer passed in isolation; it only broke where two real actions overlapped on the same order. The fix taught attribution to credit a stacked order to every action that touched it, while still counting it once toward the store total — and the lesson stuck: some failures only exist in the seams between components.

The seam that scared us most, though, hid an entire feature. Our flagship dynamic-pricing engine — the one that reprices a product from its own sales history and earns the right to auto-apply — had never once executed in the live system. Every piece of its logic was written and unit-tested, but the daily job that feeds it real history was never wired into a background loop, so the table it reads sat empty forever and its eligibility check was always false. A green test suite was hiding a completely dead feature; only tracing real data down to zero rows caught it. We wired the rollup in, backfilled real history, and added a live end-to-end test that proves it flips on. A feature isn't done when its logic passes tests — it's done when something on the live path actually calls it.

The other constant challenge was trusting a model with structure. Qwen will occasionally hallucinate an invalid layout — a section that doesn't exist, or eight where there should be three. So the renderer never trusts raw output. Every layout passes through three layers of defense, ending in a deterministic, brand-seeded fallback, so a broken store is impossible even if a model call fails entirely.

Accomplishments that we're proud of

The first time we uploaded two different logos and watched two genuinely different stores appear — not a template with swapped colors, but distinct identities Qwen chose — that was the moment it felt real.

And then watching the full loop run end to end: a simulated rush of shoppers, Qwen noticing, proposing an action grounded in what worked before, a single tap to approve, the storefront morphing live, and the dashboard attributing real revenue back to that decision. An AI that builds a store, runs it, measures itself, and learns — with a human holding the approve button. That's exactly the thing we set out to build.

What we learned

That showing the reasoning matters as much as the reasoning itself. An agent can be doing something genuinely intelligent under the hood, but if a person can't see it think, it might as well be random. So much of the work became about making Qwen's judgment legible — the trigger, the confidence, the memory it's drawing on.

And that robustness isn't a feature you add at the end — it's the thing that lets a demo survive contact with reality. Retries with backoff, graceful fallbacks, never a silent failure. The polish is the product.

What's next for Elevate

The hackathon is the starting gun, not the finish line.

Elevate is already multi-merchant — per-merchant auth and data isolation, plus real per-brand shopper accounts — and it's built to scale further into deeper integrations and an intelligence layer that compounds value the longer it runs. Per-shopper personalization, where the store adapts to each individual visitor. A self-extending config surface, where Qwen proposes entirely new capabilities from what merchants keep asking for. Cross-store learning, so a brand-new shop benefits from what worked for similar ones.

The memory gets better. The decisions get sharper.

What you're seeing here is version one of something that should have existed years ago.

Built With

Share this project:

Updates