MenuVerse-AI

AWS database usage
Architecture diagram

Inspiration

Every time we visit a restaurant, we see the same problem: outdated paper menus, slow service, and frustrated customers waiting to place orders. Restaurant owners have no idea which dishes are popular or when peak hours hit. We wanted to fix this with technology that works at any scale — from a street food stall to a global chain.

The H0 Hackathon's focus on Vercel and AWS Databases gave us the perfect stack to build something production-ready, not just a demo.

What it does

MenuVerse-AI is a full-stack restaurant operating system with three core experiences:

For Diners:

Scan a QR code at the table — no app download needed
Browse a beautiful digital menu with images, descriptions, and prices
Get AI-powered dish recommendations based on dietary preferences
Place orders in seconds and track status in real-time

For Restaurant Owners:

Full dashboard with revenue, orders, and menu analytics
AI menu import — paste unstructured text, AI extracts dishes automatically
QR code generation for every table
Real-time kitchen display with order status updates
Loyalty program, ratings, and promo code management

The Tech Stack:

Frontend: Next.js 15 deployed on Vercel
Database: AWS DynamoDB with three tables (MenuItems, Orders, Analytics)
AI: OpenAI API for menu descriptions, chat, and import parsing

How we built it

We started with the frontend branch — a complete Next.js UI with customer-facing pages and an owner dashboard. The backend branch contained DynamoDB API routes. We merged both into main for a unified deployment.

Database Schema (DynamoDB):

Table	Partition Key	Sort Key
MenuItems	`restaurant_id`	`item_id`
Orders	`restaurant_id`	`order_id`
Analytics	`restaurant_id`	`timestamp`

Key API Routes:

GET/POST /api/menu/[slug] — menu management
GET/POST /api/orders/[slug] — order processing
POST /api/ai/describe — AI dish descriptions
POST /api/ai/import — bulk menu import
GET /api/sse/stream — real-time order updates

Query Pattern Example:

For fetching a restaurant's menu, we use DynamoDB's QueryCommand:

$$T_{query} = O(1) \text{ (constant time regardless of table size)}$$

This is critical for our use case — a restaurant's menu size is bounded, but the total number of restaurants in the system could scale to millions.

Latency Target:

$$L_{target} \leq 10\text{ms}$$

DynamoDB's single-digit millisecond latency ensures the customer experience is instant, even during peak dining hours.

Challenges we ran into

1. Branch Merge Complexity We had two separate branches — frontend (UI) and backend (API routes). Merging them without breaking the UI was tricky. We had to:

Keep all frontend components untouched
Convert backend .js routes to TypeScript
Ensure no conflicting dependencies

2. DynamoDB Data Modeling Unlike relational databases, DynamoDB requires careful partition key design. We initially considered a single-table design but chose separate tables for clarity:

$$S_{storage} = \sum_{i=1}^{n} |item_i| + |order_i| + |analytics_i|$$

With on-demand capacity, storage cost scales linearly:

$$C_{storage} = 0.25\text{ USD/GB} \times S_{storage}$$

3. Real-Time Order Streaming Implementing Server-Sent Events (SSE) in a serverless Next.js environment was challenging. Vercel's serverless functions have execution limits, so we optimized the SSE stream to poll DynamoDB every 5 seconds with minimal data transfer.

4. Mock vs. Real Data The frontend had extensive mock data. We needed to ensure the app works both offline (mock mode) and online (DynamoDB mode) for development and demo purposes.

Accomplishments that we're proud of

Full-stack integration: Frontend, backend, and database all connected and working
AI features: Menu import from text, AI waiter chat, and dish descriptions
Real-time updates: Kitchen display refreshes automatically when new orders arrive
Multi-language support: 6 languages (EN, ES, FR, HI, AR, ZH) for global reach
Production architecture: DynamoDB auto-scales, Vercel edge deployment — ready for real traffic

What we learned

1. DynamoDB is not SQL We came from a PostgreSQL/Drizzle background. Learning DynamoDB's query patterns, partition keys, and sort keys was a paradigm shift. The key insight:

$$\text{Design for access patterns, not entities}$$

2. Vercel Serverless Constraints Next.js API routes on Vercel are serverless. This means:

No long-running processes
SSE requires careful connection management
Cold starts can add ~100ms latency

3. AI Integration Patterns Using OpenAI for structured data extraction (menu import) required prompt engineering. We learned to:

Provide clear output format examples
Handle partial/failed extractions gracefully
Cache AI responses to reduce API costs

4. Team Coordination With multiple developers working on frontend, backend, and deployment, clear communication was essential. Git branching strategy and environment variable management became critical.