Dinner Kaha

DinnerKaha is a fully functioning college food discovery app for MSRIT students, where students can discover nearby spots, spin a roulette wheel, check in, upvote, and view weekly campus leaderboards.

Comment

Short Project Summary

DinnerKaha is a campus-first food discovery app for MSRIT students who need a fast answer to "Aaj kya khaana hai?" Instead of copying delivery apps, it uses student check-ins, upvotes, live crowd flags, weekly hype boards, OSM-powered discovery, campus deals, and a hype-weighted roulette wheel to help groups pick where to eat in seconds.

Track

Track 1: Monetizable B2C app.

DinnerKaha fits the hospitality and local discovery space. It can monetize through campus deals, student offers, restaurant visibility, and analytics for food vendors around colleges while still solving a daily consumer problem for students.

What It Does

DinnerKaha helps college students discover and decide where to eat near campus. Students can browse nearby MSRIT/Mathikere spots, check live hype scores, spin a roulette wheel when nobody can decide, check in, upvote places, leave reviews, add community flags like "Open past midnight" or "Prices hiked", and view weekly leaderboards across categories like Overall Hype, Best Value, Late Night Kings, and Most Visited.

The app also supports adding new places through OpenStreetMap/Nominatim search. Places matched through OSM are marked as verified, while student-added places can remain community-pending.

Inspiration

The idea came from a very real problem: finding dinner near college is weirdly hard. Some places are open one week and closed the next, late-night stalls appear and disappear, prices shift because of gas hikes, and nobody in the group ever agrees on where to eat. Around campuses, some of the best spots are tiny stalls, late-night maggi counters, chai tapris, or student favorites that do not always show up well in mainstream food apps.

DinnerKaha was built for that student reality: broke, hungry, mobile-first, and tired of spending 20 minutes deciding dinner. It uses real student check-ins, live flags, upvotes, and a roulette wheel to turn messy campus food discovery into something quick, trusted, and fun.

How We Built It

DinnerKaha is a full-stack Next.js app deployed on Vercel at https://dinnerkaha.vercel.app. The frontend uses Next.js App Router, React, TypeScript, Tailwind CSS, shadcn-style components, SWR, MapLibre, and a custom dark "Midnight Dhaba" design system with Hinglish microcopy.

The backend is implemented with Next.js API routes. Data is stored in PostgreSQL using the pg driver with parameterized SQL queries. The schema includes users, places, check-ins, upvotes, reviews, flags, deals, and badges. The production target is AWS Aurora PostgreSQL, and the codebase includes support for Vercel OIDC to AWS IAM authentication through RDS Signer, so database access can work without long-lived static DB passwords.

For authentication and communication, DinnerKaha uses OTP-based login with AWS SES for email delivery, plus Google OAuth as an alternate sign-in path. For geospatial discovery, the app integrates with OpenStreetMap/Nominatim for place search and uses OSM-backed map/navigation flows for nearby discovery, directions, and adding places.

The main hype formula is:

hype_score = upvotes * 2 + check_ins * 1.5 + reviews * 1 + deal_boost - negative_flags * 3

That score powers the place cards, leaderboard rankings, and roulette wheel weighting.

AWS Database Used

AWS Aurora PostgreSQL.

DinnerKaha uses an Aurora PostgreSQL-compatible schema and SQL queries for all core application data: places, users, check-ins, upvotes, reviews, flags, deals, badges, and leaderboard scores. Aurora PostgreSQL is a good fit because the app needs relational integrity across users and places, transactional writes for check-ins/upvotes, flexible SQL aggregation for leaderboards, and a path to scalable production deployment.

Aurora PostgreSQL BD

Vercel Deployment

The app runs on Vercel as a Next.js application with API routes. Vercel hosts the frontend and backend route handlers, while Aurora PostgreSQL stores persistent user, place, check-in, review, flag, deal, and leaderboard data. The deployment uses the Vercel/AWS Aurora integration path and the docs also describe a production hardening path with Aurora Serverless v2, IAM/OIDC, and RDS Signer.

Vercel Deployment

Published Vercel Project: https://dinnerkaha.vercel.app
Vercel Team ID: TODO: add Vercel Team ID
AWS DB Screenshot: TODO: attach Aurora/Vercel Storage screenshot
Demo Video: TODO: add YouTube/Vimeo/Youku link

Architecture Diagram

Architecture Diagram

Key Features

  • Hype-weighted roulette wheel: students spin a wheel populated by nearby places, weighted by the same hype scores used by the leaderboard.
  • Real database-backed campus discovery: places, upvotes, check-ins, reviews, flags, deals, and profiles persist in PostgreSQL.
  • Live campus signals: flags like "Open past midnight", "Prices hiked", "Gas upcharge", "Closed today", and "Hygiene concern" capture real student context.
  • Weekly Hype Board: rankings across Overall Hype, Best Value, Late Night Kings, and Most Visited.
  • Check-ins and checkout flow: students can check in, confirm they are still there, and check out, powering occupancy-style signals.
  • OSM-powered add-a-spot: users can search OSM/Nominatim while adding a new place, distinguishing OSM-verified spots from community-added places.
  • Campus deals: small student offers like free chai after check-ins or budget combos under ₹99 show monetization potential without making the app feel ad-heavy.
  • Mobile-first design: the UI is optimized for hungry students using one hand while walking.
  • Security-hardened API surface: after crawler/DDoS-style abuse testing, sensitive reads now require authentication, write routes derive identity from secure sessions, request bodies are capped, JSON content type is enforced, and query parameters are validated before they touch SQL or third-party APIs.

Security & Reliability Hardening

During testing, DinnerKaha was hit by crawler/DDoS-style traffic that attempted to scrape public routes, send oversized request bodies, abuse third-party API proxy routes, and manipulate user IDs in write requests. That incident became a hardening pass across the app rather than just a one-off fix.

The API was strengthened with:

  • Authenticated sensitive GET routes: place lists/details, profiles, leaderboards, OSM search, and directions now require a valid session before returning data or calling external APIs.
  • Secure HttpOnly sessions: write actions derive userId from a signed dk_session cookie instead of trusting client-supplied userId payloads, preventing user impersonation and demo-mode writes to production.
  • Payload and content-type validation: POST routes enforce application/json and reject oversized bodies, with 10KB caps for simple actions and 50KB for reviews.
  • Input validation: route parameters such as placeId, userId, and limit are parsed as positive integers; invalid leaderboard categories are rejected; review length and rating bounds are enforced.
  • Query safety: search input escapes SQL wildcard characters like % and _, price range filters are validated before casting, and places list pagination is capped.
  • External API protection: OSM search and directions endpoints require authentication so anonymous crawlers cannot drain API quotas.
  • Safer admin flow: setup/migration secrets can be passed through authorization headers instead of query strings, keeping secrets out of logs.

These changes made the project more submission-ready by showing that DinnerKaha is not only functional, but also built with real-world abuse cases in mind.

Challenges We Ran Into

  • Balancing a reliable hackathon demo with a real database-backed implementation. The app includes demo fallbacks so judges can still explore it if the database is temporarily unavailable, while the main flows are built to persist to PostgreSQL.
  • Modeling hype in a way that feels fun but is still explainable. The score formula intentionally combines upvotes, check-ins, reviews, deals, and negative flags so community behavior directly changes discovery.
  • Designing a food app that does not feel like a clone of delivery or review platforms. The roulette wheel, live flags, Hinglish copy, and campus-first constraints helped keep the product distinct.
  • Connecting Vercel serverless functions to Aurora securely. The deployment docs use a modern Vercel OIDC + AWS IAM + RDS Signer pattern instead of static long-lived database passwords.
  • Responding to crawler/DDoS-style abuse. The project had to be hardened with authenticated data routes, payload caps, stricter content-type checks, validated query parameters, and secure server-derived sessions.

Accomplishments We Are Proud Of

  • Built a full-stack app around a very specific real audience: hungry college students near MSRIT.
  • Made the roulette wheel more than a gimmick by tying it to live hype scores from the database.
  • Created a distinctive "Midnight Dhaba" visual identity with warm dark colors, chilli-red actions, amber rewards, and Hinglish microcopy.
  • Implemented real engagement loops: check-ins, upvotes, flags, reviews, badges, and profile progress.
  • Documented a production-minded Vercel + Aurora PostgreSQL architecture with deployment and security runbooks.
  • Strengthened the app after real abuse testing, closing insecure client-supplied identity paths and protecting high-risk routes from scraping, oversized bodies, and external API quota depletion.

What We Learned

We learned that the database model shapes the user experience. Once check-ins, upvotes, reviews, flags, and deals are all stored in PostgreSQL, the frontend can become more than a static interface: the roulette wheel, leaderboard, place cards, and profile all reflect the same underlying campus activity.

We also learned that hackathon reliability and real architecture can coexist. DinnerKaha has demo fallbacks for presentation safety, but its core app structure, SQL schema, and API routes are designed around a deployable Aurora PostgreSQL backend.

The security hardening work was another major lesson: once an app is public, even a student project can be hit by crawlers and abuse traffic. Adding authentication to sensitive reads, enforcing payload limits, validating every parameter, and using HttpOnly signed sessions changed DinnerKaha from a demo into something closer to a real production service.

What Is Next For DinnerKaha

  • Add stronger college email enforcement and close development-only auth shortcuts before public launch.
  • Add true weekly leaderboard snapshots instead of live-only leaderboard views.
  • Improve abuse prevention with rate limits on check-ins, flags, reviews, and directions.
  • Add OSM write-back so community-added places can be contributed upstream to OpenStreetMap.
  • Expand from MSRIT to other Bengaluru campuses with college-specific leaderboards and place data.
  • Build a React Native mobile app using the same backend and data model.

Testing Instructions For Judges

  1. Open the published Vercel URL: https://dinnerkaha.vercel.app.
  2. Click Enter app or go to /app.
  3. If email OTP is configured, sign in with a test email. If not, use the built-in demo/peek mode.
  4. On Home, browse nearby MSRIT places and open a place card.
  5. Upvote or check in to a place and observe hype score/profile changes.
  6. Open the Wheel tab, spin the roulette wheel, and check in from the result card.
  7. Open the Nearby tab to view the campus map/list and place details.
  8. Open the Board tab to see leaderboard rankings.
  9. Open the Profile tab to see check-ins, badges, and foodie level.

Built With

Share this project:

Updates