Tablebook
Table bookings with UPI deposits for a restaurant group
Tablebook is a sample brief. We imagined a Mumbai restaurant group with a terrace in Bandra, a dining room in Fort and a bar in Lower Parel, a booking flow guests quietly hated, and tables that went empty on Saturday nights. The group is imaginary. The booking system isn't: we designed and engineered it, and you can book, pay a deposit and run the host side in the live build below.
A sample brief, a real product. We wrote this brief ourselves. The business is imaginary; the product is not: we designed and engineered it, and you can use it above. We publish results only for work a client has let us verify, so this page shows none.
The brief
We imagined a restaurant group in Mumbai with three much-loved venues, a booking flow guests quietly hated, and large tables that never showed up on a Saturday. Confirmations went out by hand on WhatsApp, and deposits were a conversation nobody wanted to have.
We asked what the booking system should be if it were as considered as the rooms, and built both sides of it: the guest's flow and the host stand.
The problem
Availability across venues is complex, and a deposit makes it harder: the table has to stay held while someone switches to a UPI app, and a company booking needs a proper GST invoice. The interface has to hide that complexity without ever lying about it.
- Availability across venues, always current
- A flow that never dead-ends
- Deposits that feel fair and refund cleanly
- A host side the front desk enjoys
The approach
We modelled the availability rules first, then wrapped them in a flow that only asks the next necessary question. Large parties and peak sittings hold a refundable deposit through a Razorpay-style checkout (UPI, cards or netbanking), the table is re-checked after payment, and the confirmation arrives as a WhatsApp Business template. Business bookings get a GST invoice with the deposit adjusted. In the demo the checkout is a sample; no money moves.
What would change for a group like this: fewer empty tables on the busiest nights, and no more chasing deposits or typing confirmations by hand.
- A booking core built around each venue's rules
- One decision per step, itemised price throughout
- Deposits, refunds and no-show charges in one ledger
- A calm host side for the people who live in it
What shipped
- Party-size-aware calendar with peak slots marked
- Slots with seat counts
- Refundable deposits for large parties and peak sittings
- Razorpay-style checkout: UPI, cards, netbanking
- WhatsApp Business API confirmation template
- GST tax invoice for business bookings, with GSTIN check
- Manage and cancel, with full refund
- Host side: service list, floor plan, guest book, waitlist
- Deposit ledger: refunds, bill adjustments, no-show charges
- Availability heatmap, reports and venue policies
Under the surface
How it is built
SvelteKit server routes talk to a Prisma and PostgreSQL core that models rooms, tables and terraces as one availability graph. Razorpay holds and refunds deposits, the WhatsApp Business API sends confirmation templates, and Fly.io runs it from Mumbai, close to guests.
- Availability solved as interval trees, not cron checks
- No double-booking: serialisable transactions, re-checked after payment
- Razorpay orders, captures and refunds, webhook-verified
- WhatsApp Business API templates with a manage link
- GST invoices with GSTIN check-digit validation
Considered and turned down
Self-hosted Cal.com got close; bespoke rules for shared spaces and deposits tipped it to custom.
Stack
The mechanism, working
The part of Tablebook that was hardest to get right, as a small model you can operate.
Interval-tree availability
Rooms, tables and terraces are one availability graph. Double-booking is impossible, not just unlikely.