Full Stack · Booking System
A car hire platform built in Django: a fleet catalogue, role-separated accounts for customers and staff, and a booking system that handles date ranges, calculates hire cost and issues a reference for every reservation. Packaged with Docker and a build script for deployment.
Demo status: not currently hosted, but the repository ships a Dockerfile, Procfile and build.sh, so it's configured to deploy. Local setup steps are at the bottom of this page.
A booking system's real difficulty is time: overlapping reservations, cancellations and status changes.
A car hire business running on a spreadsheet and phone calls double-books vehicles. The information that prevents it — which car is out, until when, and who is next in line — is exactly what a spreadsheet handles worst.
The platform gives customers a catalogue they can book from directly, and gives the operator one authoritative view of the fleet's availability.
Sole developer. I built the fleet and booking models, the role-based account system, the server-rendered interface, and the deployment configuration.
Three concerns, three apps, with templates alongside the app that owns them.
Registration, login, profiles with a role field and signal-created profiles.
Fleet catalogue with images, specifications and availability.
Booking with pickup/return datetimes, total price, status and reference.
Customers see their own bookings; staff see the full picture.
Containerised so the deployment environment is defined, not assumed.
Build steps scripted rather than documented and forgotten.
A role field on a signal-created profile keeps one user table while still separating what customers and staff can do. Fewer moving parts than parallel user models.
Storing pickup and return as datetimes makes overlap detection and duration-based pricing possible. A single date field would have made both awkward from the start.
Every booking gets a short generated reference. Support conversations use that instead of a primary key, which keeps internal IDs out of customer-facing surfaces.
Bookings move through defined states rather than being deleted on cancellation, so the operator keeps history and can distinguish a cancellation from a completed hire.
For a workflow this form-driven, Django templates ship faster and stay simpler than a separate frontend with its own build and state management.
Dockerfile, Procfile and a build script live in the repo, so deployment is reproducible rather than a remembered sequence.
The fastest way to see it working end to end.
git clone https://github.com/Eunice-ctrlz/Vehicle-Management.git
cd Vehicle-Management
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python manage.py migrate
python manage.py runserverRuns on localhost:8000. Create a superuser to manage the fleet.
I'm happy to talk through the architecture or the decisions above — and I build systems like this for other people too.