Inspiration
11.11 is a garment alteration house in Buenos Aires. Booking a short evaluation visit is a practical coordination problem because the work, price, and delivery date can only be agreed after examining the garment. I wanted to test a clearer first step and then explore how that confirmed fictional visit could move through a small workshop without hiding the human decisions.
What it does
A visitor enters a bounded Spanish request, receives nearby 20-minute slots, reviews the extracted details, and explicitly confirms a fictional visit. The post-submission update extends that flow into a separate workshop automation demo: a shared appointment ledger, a linked garment order, human capacity review, fictional customer acceptance, deposit and balance controls, a durable PDF task, and a private review queue.
The workflow checks revisions and idempotency, preserves history, blocks invalid state changes, and marks every generated document as a simulation. External delivery is disabled by default.
How I built it
I used Lovable, an AI-assisted development tool, to build and iterate on the original React, TypeScript, Vite, and Tailwind prototype. The assisted booking interaction uses deterministic browser-side rules. During the hackathon I added a Python 3.12 and SQLite automation service with a WSGI API, ReportLab PDF generation, durable queues, optimistic revision checks, integrity hashes, backups, and automated tests. The demo can run locally or in a container; its operational data stays outside the source tree.
What changed during the hackathon
The pre-hackathon prototype used a manual booking form. The first hackathon update added bounded phrase interpretation, slot suggestions, a review step, explicit confirmation, and a fresh availability check. The later automation update added the booking-to-workshop path, including shared revisions, order state controls, fictional deposit/balance logic, deterministic simulated receipts, authenticated access boundaries, and a one-command fictional scenario for reviewers.
Challenges and what I learned
The central challenge was not adding more automation; it was making each transition explicit and reversible. A booking should not silently become an order, a payment record should not become proof of a bank balance, a prepared PDF should not become a fiscal invoice, and HTTP acceptance should not become proof of customer receipt. Building those distinctions into state transitions, integrity checks, and review gates made the prototype more honest and easier to test.
Limits
This remains a simulated Alexa+ experience. It has no live Alexa+ connection, voice interface, or runtime AI model. It does not process real payments, issue fiscal documents, contact customers, or use real customer data. The automation is a separately testable demonstration of what could follow an assisted booking; it is not a production appointment, payment, invoicing, or messaging system. The organizer confirmed in the Devpost discussion that this Lovable-built deterministic browser simulation works for the simulated Alexa+ route. That clarification is not a judging result.
Testing instructions
Use only fictional data. Follow the main repository README for the original assisted booking flow. For the automation update, enter the automation-demo folder and run:
PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v
PYTHONDONTWRITEBYTECODE=1 python3 scripts/demo_scenario.py --data-dir demo-data
The test suite covers appointment revision and idempotency, the fictional deposit-to-PDF automation, PDF readability, API authentication, and the browser-origin boundary. The scenario prints the resulting revisions, queue state, document metadata, zero external messages, and zero real payments.
Built With
- docker
- gunicorn
- lovable
- python
- railway
- react
- reportlab
- sqlite
- tailwind
- typescript
- vite
