Paradiso

The brief was a website. The problem was reservations.

Paradiso is a sports bar and grill on the lakeside in Pokhara, open since 2014, with a garden that fills on event nights. The ask was a website. The actual constraint sat behind it: tables were being held over the phone and in messages, event tickets were tracked separately from table bookings, and on a busy night nobody at the door could say with confidence who had already paid.

So the site is a storefront for a booking engine rather than a brochure with a contact form. Everything visible — the hero, the gallery, the flip-book menu, the events listing — exists to move someone toward a confirmed, paid reservation, and everything behind it exists to make that reservation trustworthy at the door.

Booking a table you can actually see

Tables are real records, not a party-size dropdown. Each carries its area, its type, how many it seats, what it costs and what it comes with, so a guest picks a specific table from the floor plan rather than requesting a slot and hoping.

Selection places a soft hold against the browser session, which is the detail that stops the common double-booking failure: two people on the same table at the same moment, both midway through payment. The hold gives the guest room to finish without taking the table off the floor permanently if they walk away.

Table bookings

A specific table on a specific date, priced by table rather than by cover.

Ticket-only bookings

Event entry without a table, with each guest in the party verified individually at the door.

Both together

On event nights a booking can carry an event ticket price and a table price on one total.

Payment that clears while the guest is still on the page

Payment runs through Fonepay QR — the rail Nepali guests already have on their phones. The awkward part of QR payment is the wait: the guest scans, and the page has no idea whether it worked.

The booking holds a WebSocket open against the payment while it is pending, so confirmation arrives the moment the payment clears rather than after a refresh or a polling delay. Cash is a first-class path too, not an afterthought — a booking tracks what has actually been collected against what is owed, so a deposit taken now and the balance settled at the venue both land on the same record.

The part that runs on a busy night

Every confirmed booking carries a verification code, and the admin console is built around door staff using it under pressure: pull up the booking, check it in, mark it verified with a timestamp. Ticket-only parties verify guest by guest, with the history kept, so a group arriving in twos over an hour does not lose count.

The same console is where the venue runs itself day to day — events and past events, the table inventory, the gallery, the hero rotation, and the promotional popup, all editable without a deploy. It also drives the venue's WiFi captive portal: the images guests see when they connect, and how long they see them for, are configured from the same admin rather than from a router somewhere behind the bar.

Found before it is booked

A restaurant in a tourist town lives on being found, so search was treated as part of the build rather than a pass at the end. The backend exposes its own SEO surface, the sitemap covers the routes that matter — menu, reservation, events, gallery, contact — and the menu itself ships as a separate lightweight app so a guest on hotel WiFi can open it instantly instead of downloading a PDF.