Qwenchana

Note: Qwenchana is the project name, but we shall refer to the product as WashGo from here on.

Inspiration

Tasco already has distribution: millions of drivers, recurring mobility touchpoints, and a real service ecosystem. The gap is frequency. Most car apps are opened only when something goes wrong, when a bill is due, or when a booking is needed.

We built WashGo around a different question: what would make a driver open the app every morning, not every few weeks?

Our answer was a Qwen-powered daily copilot for car ownership. Instead of a reactive utility, WashGo becomes a proactive layer that tells the driver what matters today, why it matters, and what to do next.

What it does

WashGo is a Qwen-powered car copilot for Vietnamese car owners, built as a frontend MVP on the Tasco ecosystem.

• Morning Brief - Each session starts with a structured daily brief generated from the driver's vehicle context. It highlights service timing, issues worth watching, and suggested next actions.
• AI Vehicle Health - Qwen generates a health score, issues list, and ranked recommendations with urgency and VND pricing from the vehicle and service-history context.
• Intelligent Booking Flow - The booking page does more than show slots. Qwen adds a service brief explaining why the recommendation matters now, what to tell the mechanic, which slot is better, and how long the job should take. The page also surfaces nearby Tasco garages with direct call and directions links.
• Assistant With Tool Use - The assistant streams replies in the UI, shows tool-activity chips, and can reason over nearby services, service quotes, and booking actions using function calls.
• Dashboard Lens - Drivers can scan a warning light or a service receipt / service book. Qwen Vision returns structured results: warning explanation and urgency for dashboard symbols, or extractable service-history entries for paper records.
• Car Health Record - Lens extractions are appended into a live service-history timeline. That same record is reused by the assistant and the rest of the app, turning one-off AI interactions into cumulative vehicle memory.
• Resale Value Insight - The history page generates a valuation-style insight from the service record, giving a clear story for why maintaining a structured history matters beyond maintenance alone.

How we built it

Stack: React 19, Vite, TypeScript, Tailwind CSS, TanStack Query, Zustand, React Router, Supabase Auth, Vercel Edge Functions

We used Qwen in four different ways:

Architecturally, WashGo is built around typed service adapters and a shared Zustand session store:

• Adapter boundaries keep AI behavior behind typed contracts and deterministic fallbacks.
• Tanstack Query handles async orchestration, cache boundaries, and screen-level loading.
• Zustand session state carries cross-feature context (selected recommendation, selected garage, live health, pending assistant prompt, appended service-history entries).
• Tool execution is bounded and observable: tool-calling runs in bounded rounds (max 5) with visible tool-activity chips in UI.
• Structured output is reliability-first: all structured outputs are schema-validated before render; invalid payloads fall back to deterministic mocks.
• Bilingual behaviour is explicit: assistant follows user language (EN/VI), preserving context across turns.

That shared-state layer is what makes the demo stronger in its latest form. The vehicle-health result generated on the Vehicle page is reused by the dashboard brief, booking brief, and assistant. Lens writes new service entries into history, and the assistant sees those appended entries in the same session.

The flow essentially looks like: Vehicle Health Check -> Morning Brief -> Booking Brief -> Lens -> Assistant

Challenges we ran into

• Keeping AI claims honest while staying demo-safe - We wanted the experience to feel intelligent without breaking under live judging. That meant separating AI-generated reasoning from deterministic transaction scaffolding where necessary.
• Reliable JSON validation - Multiple features depend on structured output. We added strict validation and fallbacks for vehicle health, booking brief, vision extraction, and valuation insight so malformed outputs never break the UI.
• Cross-feature state flow - The harder product problem was not generating one answer on one page. It was making sure the result of one AI action becomes usable context for the next page. The latest implementation solves this by persisting live vehicle health and appended service-history entries in the session store.
• Vision degradation paths - Image quality varies a lot in real life and in demos. Warning-light and service-book analysis both needed deterministic fallbacks so the Lens experience still lands when the model output is weak or the API is unavailable.
• Balancing mock data with live integrations - Some surfaces are intentionally demo-safe, such as booking slots, while others can be live, such as nearby garage discovery through a server-side SerpAPI proxy and optional Google Maps rendering. Getting that balance right was critical.

Accomplishments that we're proud of

• We built a product where AI is actually load-bearing across multiple surfaces, not just bolted onto a chat box.
• The booking flow now has real intelligence layered into it: urgency reasoning, mechanic guidance, slot recommendation, and nearby garage discovery.
• The Lens-to-History loop works end to end. A receipt photo becomes structured entries, those entries appear in the service timeline immediately, and the assistant can use them in the same session.
• The assistant is grounded in app state, not isolated. It can inherit a garage selected from the map, the latest health context from Vehicle, and the latest service record from History.
• The codebase stayed disciplined under hackathon constraints: typed domain models, adapter boundaries, query hooks, shared state, and fallback-first behavior throughout.

What we learned

• The strongest AI products are not single prompts. They are systems where one model output becomes the next feature's context.
• Vision becomes much more compelling when it writes into product state instead of ending as a dead-end result card.
• Deterministic fallbacks are not a nice-to-have in demos. They are part of the product architecture.
• Booking and service flows benefit from AI most when the model explains a decision, not when it tries to own every transactional detail.
• Shared session context made the difference between "multiple AI features" and "one coherent copilot."

What's next for WashGo

• Deeper garage intelligence - Rank garages using richer criteria such as service specialty, warranty, distance, and availability instead of just displaying nearby options.
• Persistent service history - Move the car health record from session state into a real backend so it compounds over time across devices and visits.
• Telemetry ingestion - The prompt and type scaffolding already point toward tire pressure, oil level, coolant, and battery telemetry. The next step is connecting manual entry or OBD-based signals into the same record.
• Localized product UX - Add a full Vietnamese UI layer on top of the already bilingual assistant behavior.
• Used-car value workflows - Extend the valuation insight into a stronger resale and trust product built on top of the service-history record.

Built With

• alibaba-cloud-dashscope-api
• javascript
• qwen
• qwen-max
• qwen-plus
• qwen-vl-max
• qwen3-asr-flash
• react
• supabase
• tanstack
• typescript
• vercel
• zustand