OrderRoom

Stop juggling 20 WhatsApp vendor chats every morning. OrderRoom lets restaurants place all daily supply orders in 60 seconds vendors confirm by email.

Comment

Inspiration

Every morning, millions of restaurant and hotel owners wake up and do the same exhausting thing open WhatsApp and manually type the same supply orders to 15, 20, sometimes 30 different vendors. Vegetables to one vendor. Meat to another. Dairy, beverages, packaging each a separate chat, each typed manually, each with zero confirmation tracking.

We watched a restaurant owner spend 45 minutes every single morning doing this. Three vendors missed his messages that day. One misread a quantity. By lunch, two ingredients were missing. He lost thousands in a single afternoon.

This happens every day. Across millions of food businesses. And nobody has solved it because every existing tool requires vendors to sign up, install apps, and learn new software. A local vegetable farmer or dairy supplier is not going to do that.

That frustration became OrderRoom.

What It Does

OrderRoom is a buyer-first vendor order management platform built for restaurants, hotels, and catering businesses.

For the restaurant owner:

  • Signs up in 5 minutes
  • Adds vendors once name, email, category
  • Adds products with default quantities per vendor
  • Every morning: open OrderRoom → quantities are pre-filled → click Send Orders to All Vendors
  • Done in under 60 seconds

For the vendor:

  • Receives a professional email showing exactly what was ordered
  • Clicks one green Confirm This Order button
  • Sees a success confirmation screen
  • Total time: 10 seconds

No vendor account. No app download. No registration. No training needed. Works on any phone, any email client, anywhere in the world.

Core Features:

  • Today's Order Status Board - live Kanban grid showing all vendors with real-time color-coded status: Draft → Sent → Confirmed → Delivered
  • Summary statistics - Active vendors, Orders today, Confirmation rate, Average order completion time
  • Real-time activity feed - powered by AWS DynamoDB event streaming
  • Vendor issue alerts - if a vendor reports a problem, the owner is notified immediately on the dashboard
  • Full order history - complete audit trail of every order, every vendor, every day
  • Billing management - Stripe subscription plans with enforced vendor limits
  • 3D premium UI - mouse-tracking perspective animations, floating gradient orbs, glassmorphism cards

How We Built It

Frontend

Built with Next.js 14 App Router and Tailwind CSS, deployed on Vercel's edge network. UI components use shadcn/ui built on Radix UI primitives for full accessibility compliance.

The landing page features a full 3D interactive experience:

  • Mouse-tracking perspective tilt on the dashboard mockup using CSS transform: perspective(1000px) rotateX() rotateY() driven by JavaScript mousemove events
  • Animated gradient orbs (amber, blue, purple) floating in the background with CSS keyframe animations
  • Glassmorphism cards with backdrop-filter: blur()
  • Intersection Observer-triggered scroll animations on every section
  • Animated number counters on dashboard statistics using requestAnimationFrame

Authentication

NextAuth.js with credentials provider. Passwords hashed with bcrypt at 12 salt rounds. Sessions stored as HTTP-only JWT cookies. Every API route validates businessId from the session — enforcing row-level data isolation without a database-level policy engine.

Primary Database - AWS Aurora PostgreSQL

All relational, transactional business data is stored in AWS Aurora PostgreSQL Serverless v2, provisioned directly in AWS Console, running in us-east-1 (N. Virginia).

DB Identifier: orderroom Engine: Aurora PostgreSQL Mode: Aurora Serverless (auto-scales with demand) Region: us-east-1c Status: ✅ Available

Table Purpose
Business Restaurant / hotel / catering company profile
User Staff accounts with bcrypt-hashed passwords and roles
Vendor Supplier profiles — name, email, category
Product Items per vendor with default quantities and units
Order Daily order records with date, status, and notes
OrderItem Line items linking orders to vendors and products
Subscription Plan tier, vendor limits, Stripe billing references

Each OrderItem carries a unique confirmToken - a cryptographically generated identifier (cuid) that powers the zero-authentication vendor confirmation flow. The vendor's email contains a link with only this token. The server validates it, updates the OrderItem.vendorStatus to confirmed, records the confirmedAt timestamp, and simultaneously writes a VENDOR_CONFIRMED event to AWS DynamoDB - all in a single atomic operation.

Why AWS Aurora PostgreSQL: This data is deeply relational. An Order connects to a Business which has Vendors each with Products. OrderItems reference an Order, a Vendor, and a Product simultaneously - SQL JOINs are essential. ACID compliance is non-negotiable: a missed write on an order record means a missing ingredient at lunch service, which costs real money. Aurora Serverless automatically scales compute capacity with demand, making it the right choice for a B2B SaaS product with variable daily usage patterns.

Event Database - AWS DynamoDB

All real-time events are logged to AWS DynamoDB in the orderroom-events table.

Attribute Type Purpose
eventId String (Partition Key) Unique UUID per event
timestamp String (Sort Key) ISO8601 for time-ordering
businessId String (GSI) Filter all events per business
orderId String Reference to Aurora PostgreSQL order
orderItemId String Reference to specific line item
eventType String ORDER_SENT, VENDOR_CONFIRMED, VENDOR_REJECTED, ITEM_DELIVERED
actorType String system / vendor / owner
metadata String JSON payload with additional context

Why AWS DynamoDB: These are high-frequency, independent events with no JOIN requirements. When 20 vendors confirm orders simultaneously, DynamoDB handles all 20 concurrent writes without lock contention. The access pattern is always the same get all events for a businessId ordered by timestamp which maps perfectly to our GSI design. DynamoDB is genuinely the architecturally correct tool for this workload, not a choice made for optics.

Full System Architecture

┌─────────────────────────────────────────────┐

│ RESTAURANT OWNER (Browser) │

│ Dashboard · New Order · Vendors · History │

└──────────────────┬──────────────────────────┘

│ HTTPS

┌──────────────────▼──────────────────────────┐

│ VERCEL EDGE NETWORK │

│ Next.js 14 — App Router │

│ Server Components · API Routes · Middleware │

│ NextAuth.js Session Layer │

└──────┬──────────────┬───────────────┬───────┘

│ │ │

┌──────▼──────┐ ┌─────▼──────┐ ┌─────▼────────┐

│ AWS Aurora │ │ AWS │ │ Resend API │

│ PostgreSQL │ │ DynamoDB │ │ │

│ Serverless │ │ │ │ Vendor order │

│ │ │order_events│ │ emails with │

│ Businesses │ │ table │ │ confirm link │

│ Vendors │ │ │ └──────────────┘

│ Products │ │ ORDER_SENT │

│ Orders │ │ CONFIRMED │ ┌──────────────┐

│ OrderItems │ │ REJECTED │ │ Stripe API │

│ Subscriptions│ │ DELIVERED │ │ │

│ Prisma ORM │ │ AWS SDK v3 │ │ Subscriptions│

└─────────────┘ └────────────┘ │ Plan limits │

│ Webhooks │

┌─────────────────────────────┐ └──────────────┘

│ VENDOR (Any Phone/Email) │

│ Email → click Confirm → │

│ Token lookup in Aurora → │

│ Status updated → │

│ DynamoDB event logged │

└─────────────────────────────┘

Email System

Resend API with React Email templates. Each vendor receives a responsive, mobile-optimized email with their specific order items in a clean table. The confirmation URL contains only the unique confirmToken. The rejection flow includes a free-text field for reporting issues the message is stored in DynamoDB metadata and surfaced on the owner's dashboard activity feed immediately.

Payments

Stripe subscriptions with webhook handling. Plan limits are enforced server-side on every vendor creation API call. A soft paywall is shown when the free plan limit is reached, with a direct one-click upgrade to Stripe checkout. Customers can manage their billing through the Stripe Customer Portal accessible from the dashboard settings page.

Challenges We Ran Into

1. Zero-Authentication Vendor Confirmation The hardest design challenge was making vendor confirmation work with absolutely no authentication. The solution was a unique cryptographic token (confirmToken a cuid) generated per OrderItem at order creation time, stored in AWS Aurora PostgreSQL. The public Next.js route /confirm/[token] validates this token, updates the order status atomically, and writes the event to DynamoDB simultaneously. Getting the transaction boundary right between two different databases ensuring neither a partial update nor a double-write could occur required careful handling of error states and rollback logic.

2. Dual Database Consistency Without a Coordinator Maintaining consistency between AWS Aurora PostgreSQL (source of truth for order state) and AWS DynamoDB (event log) without a distributed transaction coordinator was a real architectural challenge. We resolved this by treating DynamoDB as an append-only audit log if a DynamoDB write fails after a successful PostgreSQL update, the order state is still correct and the event is simply missing from the log. This is the correct tradeoff: order integrity is preserved, and the activity feed may have a rare gap rather than a corrupted order record.

3. Real-Time Dashboard Feel Without WebSockets Delivering a genuinely live-feeling dashboard using Next.js server components and periodic polling rather than a WebSocket connection keeping architecture simple while maintaining the real-time UX experience that makes the product feel like a funded startup tool rather than a student project.

4. Mobile-First Vendor Experience The confirmation page must work perfectly on a basic Android phone opened directly from a Gmail notification. No frameworks. No JavaScript required to confirm. The page renders server-side with the complete order details and a large tap-friendly button. Every pixel was designed with a low-end mobile device as the primary target because that is the real-world vendor.

5. Building Full Production Stack in 3 Days Authentication, two AWS databases, email delivery, Stripe payments, 3D landing page, full dashboard, vendor management, order history, billing page, architecture page, blog post, and deployment all in 72 hours. Prioritization and scope discipline were as hard as any technical challenge.

Accomplishments That We're Proud Of

  • Zero-friction vendor confirmation - the single most important design decision in the product, executed cleanly. A vendor with a basic phone and no tech knowledge can confirm an order in 10 seconds.
  • Dual AWS database architecture - AWS Aurora PostgreSQL and AWS DynamoDB, each chosen for a genuine, explainable architectural reason, not for optics
  • Full production-ready stack - auth, email, Stripe payments, two AWS databases, edge deployment — all working end-to-end
  • 3D premium visual design - the landing page and dashboard look and feel like a funded startup product
  • Real monetization - actual Stripe integration with enforced plan limits, a real free tier, and a real upgrade flow. Not a fake pricing page.
  • Honest architecture - every technical decision in this project can be explained and defended. Nothing was added to impress. Everything was added because it was right.

What We Learned

  • The hardest user in B2B SaaS is not your customer it is your customer's counterparty. The vendor experience had to be designed for someone with zero technical knowledge, zero motivation to learn a new tool, and 10 seconds of patience. That constraint shaped the entire product architecture.
  • DynamoDB access pattern design is a pre-code decision. The GSI structure determines every downstream query. We learned this early and designed the schema before writing a single line of application code.
  • Vercel + Next.js App Router is genuinely fast for full-stack development. Server components, API routes, middleware, and edge deployment in one framework reduced context-switching dramatically.
  • Aurora Serverless v2 cold starts are real. The first query after an idle period takes longer. For a hackathon demo, this required keeping the database warm with a periodic ping.
  • Scope discipline wins hackathons. We cut WhatsApp API integration, AI order suggestions, and mobile app plans. What shipped is complete, working, and demonstrable. Incomplete ambitious features lose to complete simple ones every time.

What's Next for OrderRoom

  • WhatsApp Business API integration - vendors who prefer WhatsApp over email can confirm directly in their existing chat interface
  • AI-powered order suggestions - "Based on your last 4 Saturdays, here is what you will likely need today" using historical order pattern analysis
  • Delivery window scheduling - vendors specify delivery time slots, owner sees a consolidated delivery calendar for the day
  • Multi-location support - restaurant chains managing procurement across multiple branches from a single owner account
  • Vendor performance analytics - response rate, on-time delivery rate, rejection rate, and reliability score per vendor over time
  • Mobile app - React Native application optimized for the morning ordering flow on phones
  • Automated reminders - if a vendor has not confirmed within 2 hours, an automated follow-up email is sent and logged in DynamoDB
  • Integration marketplace - connect with existing POS systems and inventory management tools to auto-generate order suggestions from live stock levels

Built With

Share this project:

Updates