Case study
Table booking across several venues, from the guest's form to the staff seat map
One system runs the bookings of Habibi's venues: guests book on two websites, staff see the day and the tables in one workspace, and the printed QR codes and campaigns can be changed from that workspace.
- System
- Booking and guest system
- Period
- October to December 2025
- Status
- Live
- Last extended: October 2026
- Technology
- Next.js, TypeScript, PostgreSQL (Supabase), Konva, Resend
An evening on the map
Tables, their states and a waitlist on one venue's evening. The bookings are made up.
Terrace, Friday evening
- T12 guests19:00
- T22 guests
- T34 guests19:30
- T44 guests18:30
- T56 guests20:00
- T62 guests
- T74 guests20:30
- T88 guests21:00
Waitlist
- 20:30
- 21:00
What the team needed solved
One booking system for several venues, from the guest's form to the staff's table map.
Two venues take bookings on a website we do not run, and their bookings have to work regardless of it.
The cards are printed once, while the destination and the campaign behind them can change at any time.
What we built
Bookings for three venues
One system takes the bookings of Habibi Skybar, Habibi Vár and Habibi Nagymező. Guests get the same rules, messages and confirmation whichever form they use.
An embedded booking form on another site
Habibi Vár and Habibi Nagymező take bookings on habibibudapest.com, a site we do not run. The site loads one element and one script from us, with no iframe, and takes its language from the page.
A waitlist
When no table is free, a guest can join the waitlist. When a place opens up, staff send an offer, which the guest accepts or declines from the email.
A confirmation email
The guest gets an email confirmation with a cancellation link and a calendar file.
The staff workspace
Per venue: the day's bookings, arrivals, free tables, the guest list and statistics. A venue admin manages their own venues; the statistics role sees the numbers only.
A seat map with its editor
Tables are moved, rotated and resized on the same map staff use to see the evening's bookings, so the editor and the live map cannot disagree. Areas, with a floor plan behind them.
Re-targetable QR codes
A card is printed once. Where it leads, a page, an external link or an uploaded PDF, can be changed from the workspace at any time.
A coupon campaign
A guest scans a card, leaves an email address once, and the coupon arrives a couple of minutes later. The campaign's code, image, wording and validity are edited in the workspace, with no new release.
How it works
One booking
Form or embedded booking
The guest books on habibi.hu or on habibibudapest.com.
A free table
The system looks for a table within opening hours and reserves it in one step. If there is none, the waitlist.
Confirmation
An email with a cancellation link and a calendar file.
Staff
The booking appears on the venue's day list and on the seat map.
From card to coupon
Printed card
The code carries one fixed address that does not change.
Campaign
Behind the address, the campaign set in the workspace: code, image, wording, validity.
Coupon
One address, once: the coupon arrives by email.
How we built it
Limits on the public booking form
Only approved sites can book. Each address may make five bookings in ten minutes, a hidden field and the time taken to fill the form filter out bots, and there are caps per email address, per venue per night and overall.
It stops on a fault
If the counter or a cap cannot be read, the booking does not go through, and the guest is told to call the venue.
No stored IP addresses
The limits are keyed on a salted hash of the address; no raw address reaches the database.
Seating in one step
Assigning a free table is a single atomic database function that only the server can call, so the public key cannot get around the checks.
Map saves without collisions
A save takes the same per-venue lock as a booking, writes in one transaction, and writes nothing if someone else saved in between. Tables are never deleted: a retired table stays for the bookings it already had.
A tested booking flow
The unit tests run the real sequence of steps against a fake database, and check that every rejection happens before anything is written.
Several venues, and one system for all of them?
Write down where your guests book today and what your team sees of it. We start from what you write.
A person reads what you send and replies to exactly that.