Tablify — Table Reservations with Table Sharing

Problem

Our client, a network of restaurant owners, was still running reservations from a paper notebook and phone calls. That meant booking errors, tables left empty and no real-time view of how full the room actually was.

They wanted something modern that would fill more seats, and they also wanted to make dining more social by letting guests share a table with strangers.

The solution

Tablify is an online table reservation platform built for both sides of the restaurant:

• Guests create an account, find a restaurant and book a table for a date, a time slot and a number of people, with the option to open their table to others
• Restaurant owners get a management dashboard where they can see, accept or decline reservations
• IoT sensors on the chairs (Raspberry Pi Pico) report which seats and tables are occupied, so the dashboard shows occupancy in real time
• Confirmation and notification emails are sent automatically through SendGrid

Unlike OpenTable or TheFork, Tablify combines IoT occupancy tracking with built-in table sharing.

My role

We were a team of four over six months, working in three sprints plus a testing phase, with weekly client meetings. Each of us owned one area of the product. Mine was restaurant management, the part restaurant owners use every day:

• Creating and managing a restaurant: name, address, contact details
• Opening hours for each day of the week, validated on both client and server so a closing time can never come before the opening time, and with support for days the restaurant is closed
• Table availability per time slot, so a restaurant controls its capacity and can't be overbooked
• The restaurant dashboard, which brings reservations, opening hours and tables together in one place
• Changing and cancelling a reservation, which frees up the table and sends a confirmation
• Customer reviews, which the restaurant can read and reply to publicly

I wrote these user stories with acceptance criteria and test scenarios, then built them across the Next.js + shadcn/ui front-end and the Express + PostgreSQL API.

Architecture & deployment

• Front-end: Next.js, TypeScript and Tailwind CSS
• Back-end: a REST API in Node.js / Express.js with TypeScript, using JWT authentication
• Database: PostgreSQL, with parameterised queries to prevent SQL injection
• Hosting: a Hostinger VPS running the front-end, back-end and database as Docker containers behind an Nginx reverse proxy, with HTTPS from Let's Encrypt
• Workflow: feature branches, documented pull requests reviewed by the group, GitHub Actions checks and GitHub Projects for sprint tracking

What worked

The client signed off on the core features: online booking, user and restaurant management, IoT sensor integration and real-time table tracking. They were keen to roll it out more widely.

What I'd do differently

Plan the final testing phase earlier. Some edge cases, like a dropped network connection or timeouts on the Raspberry Pi link, came up late. Auto-generated API documentation (Swagger) would also have made the API easier to work with across the team.