Restaurant Management System

Overview

A full-stack Django web app built to give a restaurant one place to handle three things that normally live in separate tools: table reservations, meal ordering, and a blog platform for sharing updates and promotions. Customers land on the marketing site, browse the menu, reserve a table, place an order, or read the latest kitchen notes — all through the same Django app.

The goal was to practice real full-stack Django (not just the ORM tutorial) with a production database path, admin dashboard, and a deployable build.

Features

• Real-time table reservations — customers check table availability and reserve a spot in real time. No overbooking, no double-booking.
• Meal ordering — browse the menu, build an order, place it. Clean customer-facing UI + order management in the admin side.
• Integrated blog — a Django-powered blog platform so the restaurant can publish updates, promotions, and culinary stories without bolting on a separate CMS.
• Admin dashboard — the Django admin, extended with custom models for tables, reservations, menu items, and blog posts.
• User accounts — Django’s built-in auth for customers and an admin superuser for restaurant staff.

Stack

• Backend — Django with Python, classic MVT architecture.
• Database — SQLite for local development, PostgreSQL for production. Migrations managed through Django’s makemigrations / migrate commands.
• Frontend — HTML templates, CSS, and vanilla JavaScript. No SPA — everything is server-rendered.
• Deployment — Gunicorn as the WSGI server, collectstatic for static assets, Nginx or Apache as a reverse proxy in the deploy docs.

Notable bits

• Django’s admin as a product surface — instead of building a bespoke staff dashboard from scratch, I leaned on the admin and customized it, which let a small project ship a full staff UX almost for free.
• Three apps in one project — reservations, ordering, and blog each live as separate Django apps with their own models and URLs, so any one of them could be pulled out and reused independently.
• Production migration path — SQLite → PostgreSQL wasn’t just changing the settings. The exercise forced me to think about data types, indexes, and connection pooling from the start.

Why archived

This project was a learning vehicle for full-stack Django — how models, views, templates, admin, and deploy glue together in one coherent app. It still runs, but it’s no longer something I’m actively developing.