KANDYPACK
A system for a delivery business to keep track of customers, products, drivers, and warehouses in one place, built as a university group project and packaged with Docker so it runs the same way everywhere.
The problem
A delivery operation has to keep customers, products, drivers, and warehouses consistent with each other as orders move through the pipeline, which needs a schema that actually models those relationships and a deployment setup the whole team can run identically instead of fighting local environment differences.
The approach
Built as a university group project: an Express and MySQL backend with JWT-based auth, and a React, Vite, and TypeScript frontend built on shadcn/Radix components for managing customers, products, deliveries, drivers, and warehouses. My focus was the database, designing the schema behind those entities, and the deployment: containerizing the whole stack with Docker, with a docker-compose override for hot-reloading in development and a separate production compose configuration.
What I learned
Setting up one Docker configuration for development (fast rebuilds, live mounts) and another for production (lean, no dev dependencies) instead of forcing both through the same setup made the split between 'built for iterating' and 'built for running' concrete rather than theoretical.