A queue is a bad use of a 30-minute break.

A college break is short and fixed. The canteen rush is short and fixed too, and it lands at exactly the same time for everyone. The result is a queue that can take a third of the break, followed by eating in a hurry.

The canteen has the mirror-image version of the same problem: a crush of people all arriving at once, orders taken verbally under time pressure, cash handled at the counter, and no way to know what to prepare until someone is standing in front of you asking for it.

BiteSite moves the ordering and the paying off the counter and into the phone, before the break starts. The student picks from their canteen’s live menu, pays online, and gets a notification when the food is ready. The only thing left at the counter is handing the food over.

For the canteen, that turns an unpredictable rush into a queue of paid orders it can see and work through, with the money already collected before anything is cooked.

BiteSite is multi-tenant. Every college that joins gets its own isolated space on the platform: its own outlets, its own staff accounts, its own menu and pricing, and its own orders. A student account belongs to exactly one college and can never see another college’s data.

That isolation is enforced in the software rather than by convention, and it is covered by automated tests, because it is the thing that has to hold for a shared platform to be trustworthy.

Prepayment only works if the refund path is at least as reliable as the payment path. So a paid order that gets cancelled is refunded through the gateway before the cancellation is recorded, rather than after, and staff cannot mark an order paid without a real payment behind it.

We never see your card, UPI or bank credentials. Those go to Razorpay, our payment gateway, and we keep only the amount, the reference, and whether it worked.