Booking and Management Platform for Restaurants

Case study · Fullstack web development · Astro · Node.js · MySQL · Docker

Stopping a restaurant from losing customers over a paper booking log

A booking taken by phone and jotted in a notebook, an employee who takes a day off without passing on the information, and the table promised weeks in advance is no longer available when the customer arrives. In the kitchen, the menu shown online is already out of date and the dish ordered no longer exists. An evening meant to be perfect turns into frustration, both for the customer and for the table next door caught in the resulting service delay.

Braise is the platform I designed and built, from the first sketch to the Docker infrastructure, to eliminate this kind of friction: online booking, table management and digital ordering brought together in a single tool, built around the real frustrations of customers and restaurant owners rather than a checklist of features.

The problem: two frustrations, one service under strain

From the restaurant owner's point of view, a good night becomes the problem: between phone calls, walk-ins and bookings scribbled in a notebook, names, tables and time slots end up blending together. Juggling takeout orders and in-house service slows down the whole team. The result: double-booked tables, a kitchen discovering the covers at the last minute, and staff wearing themselves out fixing avoidable mistakes.

Scoping the project surfaced precise needs, at the intersection of the customer experience and kitchen organization:

• Centralize bookings: every reserved table recorded once, visible to the whole team in real time, with no dependence on a notebook or a verbal handover between staff.
• Make the online menu reliable: the menu a customer checks before coming in should be exactly what the kitchen can actually serve at the moment of ordering, with stock-outs reflected immediately.
• Enable online ordering for dine-in, takeout or delivery, with a preparation status shared between the floor and the kitchen.
• Anticipate preparation using the booking time, to reduce the wait between a customer's arrival and the dish being served.
• Give management full control, without depending on a developer for every menu change or promotion.

The features: a platform seen through four roles

Braise was built as a system designed from four points of view: the customer who books and orders, the server who manages the floor in real time, the kitchen that tracks orders, and management, which oversees the whole operation.

Online booking and floor plan

Customers book their table by date, time and party size, with automatic confirmation or manual approval depending on the settings chosen. Every booking shows a clear status (confirmed, pending, completed), visible in real time to the whole team, so no one ever has to rely on a notebook or a handwritten note again.

Dynamic digital menu

The menu shown online finally matches the kitchen's: illustrated categories, allergens, tags (vegetarian, spicy, popular) and availability updated in real time. A dish that runs out disappears instantly from the public menu, with no manual step.

Ordering and online payment

Customers order for dine-in, takeout or delivery, and pay online securely. Every order follows a precise status (received, in preparation, ready, delivered), shared between the floor and the kitchen so both teams work off the same information.

Loyalty and customer reviews

Loyalty points convertible into rewards, customizable promo codes and review collection after every experience turn a one-time customer into a regular.

Admin dashboard

A single interface to manage the menu, bookings, active orders, sales statistics and promotions, without ever needing an emergency call to a developer for a routine change.

Roles and traceability

Admin, manager and server accounts with distinct permissions ensure each team member only accesses what concerns them, with an activity log that traces every sensitive action.

The process: architecture decisions driven by service, not trends

Once the features were defined, the real question remained: whether the platform holds up on an actual Friday night. Rather than starting from a trendy framework, every architecture decision answered a real constraint of running a restaurant.

1. Never interrupt service for an update

The risk identified from the start was simple: a minor site update, a changed photo, a design fix, should never require restarting the servers in the middle of order taking. The Astro frontend and the Express API therefore live in two separate repositories, with their own pipelines. The static site can be rebuilt and republished without ever touching the application containers handling live bookings and payments.

2. Loading speed built for a customer in a hurry, on mobile

A customer hesitating in front of the storefront, phone in hand, won't wait several seconds for a page to load. Astro's islands architecture isolates JavaScript to only the truly interactive zones (the booking form, the order cart, the admin dashboard) and lets the rest of the page, menu, presentation, reviews, load as near-instant static HTML. LCP stays fast since no hydration blocks the main content from rendering, and CLS is kept in check thanks to image dimensions reserved upfront.

3. A backend built to absorb the rush

On the kitchen side, when orders start piling up, the Express API exposes a dedicated monitoring endpoint and the MySQL connection pool avoids opening a new connection per request. It's precisely this kind of detail that absorbs the lunch and dinner rush without flinching, when bookings and orders concentrate into very short windows.

The tech stack

Every technical layer was chosen to answer a concrete constraint of the restaurant business, rather than to follow a trend.

Frontend and content

• Astro for the public content (menu, storefront, reviews), mostly static and consulted on mobile: pure HTML, no JavaScript by default, well suited to a 3G connection outside the restaurant
• Native Astro FR / EN / ES routing, with content translated and indexed separately by search engines, no third-party client-side i18n library, for an international customer base

Backend and data

• Node.js and Express for a lightweight REST API, without a heavy ORM, between the Astro frontend and the database, sufficient for the traffic volume of an independent restaurant
• JWT and bcrypt for stateless authentication, suited to an API consumed both by the public site and the back office, with password hashing meeting current standards
• MySQL as the relational database, well suited to a strongly linked model (bookings, orders, payments, loyalty) with strong integrity constraints

Deployment

• API, MySQL and phpMyAdmin containerized separately and orchestrated with Docker Compose, served behind an HTTPS reverse proxy
• Astro frontend built as static and shipped independently, for two fully decoupled deployment cycles

The result: the evening that no longer turns into a fiasco

With Braise in place, the ruined-Friday-night scenario no longer happens: bookings come in online and confirm themselves, the menu shown on the site is the one the kitchen just updated from the dashboard, and every order tracks its status in real time all the way to the floor.

This project starts from a frustration experienced by both the customer and the restaurant owner, works out the real priorities from it, then picks each technical building block (Astro, Node, MySQL, Docker) for what it actually solves, not for its popularity. Planned next steps include integrating a real payment provider, automated API testing, and real-time notifications between the kitchen and the floor.

Case study written as part of a web development portfolio. Personal project, simulated client brief.

Fullstack developer · web platforms for the restaurant industry