TRAY — Campus food, without the queue

One campus, every canteen, zero queues — live ordering, kitchen operations, direct UPI, and verified pickup in one realtime system.

Comment

Inspiration

At 12:47, a campus canteen is not a food problem. It is a coordination failure: students lose class time in a crowded queue, kitchen staff shout over paper tokens, and owners either stay stuck with cash and chits or surrender a large share of every order to delivery aggregators.

TRAY gives a college canteen the infrastructure of a modern quick-service operation without requiring an IT team, a custom app agency, or a commission-heavy marketplace.

What it does

TRAY is a multi-tenant operating system for campus food.

A single deployment gives every stakeholder a purpose-built portal:

  • Student app: switch between campus canteens, browse live availability, choose dine-in or takeaway, pay by UPI, track preparation in realtime, and collect using a 4-digit OTP.
  • Kitchen board: receive tickets instantly, see prep totals, advance orders through the live queue, create walk-in orders, mark items sold out, reject or undo actions safely, and complete OTP handovers.
  • Canteen admin console: manage menus, staff, opening hours, orders, revenue, peak-hour analytics, audit history, and CSV exports.
  • College portal: see multiple counters in one campus-wide view while preserving strict per-canteen access boundaries.

Payments go directly to the canteen through Razorpay. TRAY takes 0% commission and never holds the canteen's money.

What changed for OpenAI Build Week

TRAY existed before the submission period as a campus-ordering concept. During OpenAI Build Week, it was meaningfully extended into the current product at https://trayy.vercel.app.

The Build Week extension focused on making the system coherent, testable, and production-minded across the whole journey:

  • A complete new visual and interaction system across the landing experience, student app, kitchen board, and admin console
  • A no-sign-up live demo path for all major portals
  • Multi-canteen campus navigation and clearer role-based information architecture
  • Dine-in/takeaway flows with context-aware pickup copy and ETA states
  • Realtime menu, queue, status, and sold-out synchronization across portals
  • Kitchen-first UX: large touch targets, prep totals, walk-in orders, undo windows, rejection reasons, connection recovery, and OTP handover
  • Stronger admin operations: live KPIs, revenue trends, peak-hour heatmaps, menu/staff controls, order history, auditability, and exports
  • More explicit reliability and security guarantees around tenant isolation, payment verification, stock races, retries, and failure recovery
  • Updated architecture, setup, testing, and security documentation for judges

The repository history and Codex session provide dated evidence distinguishing the Build Week work from the earlier version.

How Codex and GPT-5.6 were used

Codex with GPT-5.6 acted as an engineering partner for the Build Week extension. I retained ownership of the product direction, campus workflow, visual decisions, and final trade-offs; Codex accelerated implementation and verification.

It was used to:

  • map the existing product into clearer student, kitchen, admin, and college-level boundaries
  • turn UX decisions into reusable React and TypeScript components
  • refactor route groups and tenant-aware flows without weakening isolation
  • reason through race conditions such as duplicate payment webhooks and two students ordering the final item
  • iterate on realtime reconnection, fallback, and failure states
  • review SQL migrations, RLS policies, atomic database functions, and payment validation paths
  • strengthen tests, setup instructions, architecture notes, and judge-facing documentation

GPT-5.6 was especially useful for reasoning across the full system rather than treating each screen as an isolated feature: what the student sees must match what the kitchen prepares and what the admin measures.

How it works

  1. A student selects a campus canteen and browses its live menu.
  2. The cart is isolated per canteen and supports dine-in or takeaway.
  3. UPI opens through a mobile deep link or desktop QR.
  4. Razorpay webhooks are HMAC-verified.
  5. A row-locked Postgres function validates the paid amount, prevents duplicate capture, updates the order, and emits the realtime event atomically.
  6. The order reaches the kitchen board and student tracker in under a second.
  7. Staff prepares the order and verifies the 4-digit pickup code before completion.

Technical implementation

  • Next.js 15 App Router, React 19, and strict TypeScript
  • Tailwind CSS 4 with separate design systems for student, kitchen, and admin contexts
  • Supabase Postgres, Auth, Realtime, and database-level Row Level Security
  • Append-only order events for efficient realtime fan-out
  • Razorpay UPI with HMAC verification, amount validation, idempotency, reconciliation, and a dead-letter queue
  • Atomic row locks for payment capture and finite-stock checkout
  • Upstash Redis and QStash for rate limiting and background jobs
  • Sentry and structured JSON logging for production diagnostics
  • Vercel deployment with Edge middleware for tenant resolution

Key engineering decisions

Database-enforced tenant isolation

Every row carries a tenant identity, and Postgres RLS enforces access. A forgotten application filter fails closed with zero rows instead of leaking another canteen's data.

Atomic payment and stock transitions

Money and inventory cannot depend on optimistic UI. Row-level locks ensure that duplicate webhooks are harmless and that only one of two concurrent students can buy the final samosa.

One source of truth across three portals

Student, kitchen, and admin views subscribe to the same append-only event stream. Realtime push is backed by polling and exponential reconnect so a weak campus network does not freeze operations.

Challenges

The hardest part was not building another ordering screen. It was making guarantees hold across payment retries, network drops, multiple tenants, simultaneous checkouts, and different staff roles while keeping the interface simple enough for a busy counter.

The kitchen experience also required a different design mindset from a normal dashboard: low-end tablets, wet or gloved hands, noise, urgency, accidental taps, and almost no tolerance for ambiguous states.

Accomplishments

  • One deployment supports multiple colleges and canteens without per-tenant code changes
  • Three live operational portals stay synchronized from one source of truth
  • Direct UPI settlement and 0% order commission
  • Database-enforced tenant isolation
  • Atomic capture, idempotency, stock protection, and webhook recovery
  • A complete no-sign-up demo that judges can explore immediately
  • A coherent product experience rather than a disconnected proof of concept

What I learned

A polished screen is not a reliable product. Reliability comes from deciding where guarantees live: tenant isolation in the database, money transitions inside locked transactions, and operational state in one append-only event stream.

I also learned that AI-assisted development is strongest when the human owns the problem and the trade-offs. Codex made implementation and review dramatically faster, but the useful results came from feeding it concrete constraints from the real environment: lunch rushes, weak Wi-Fi, direct UPI economics, low-end hardware, and non-technical staff.

Try it

No account is required for the demo:

What's next

Inventory forecasting, ingredient-level waste tracking, scheduled pickup, meal plans, loyalty, and campus-wide demand planning. The same tenant, queue, payment, and handoff engine can later serve office cafeterias, hospitals, stadium counters, and other high-volume food operations.

Built With

  • codex
  • framer-motion
  • gpt-5.6
  • gsap
  • next.js-15
  • postgresql
  • qstash
  • razorpay
  • react-19
  • row-level-security
  • sentry
  • supabase
  • supabase-realtime
  • tailwind-css-4
  • typescript
  • upstash-redis
  • vercel
  • zustand
Share this project:

Updates

Submission history