Case study · school project
Delivery robot platform
A web app for the company that makes delivery robots, the API behind it, a simulated platform for the robots to talk to, a robot you can run on a phone, and a small ESP32 board that shows what the robot is doing.
Source on GitHub (private) See it in the museum Walk it in 3D
- Course
- Advanced Full Stack Development, Howest MCT
- Year
- 2026
- Parts
- Web app, API, simulator, robot, ESP32
- Run it with
- One command, or Docker
The brief
The customer builds small delivery robots on wheels and wanted a web app of its own, not another screen in the ordering platform. The wishes were specific: no staff or customer data in it, defects and replacements, roles per company with a way to view the app as a role, one isolated food robot instead of a mixed cargo, and no Google login. A later round added what to do when a robot is stolen or goods are lost: a dossier with what is gone, where, when and what happened, that downloads as a PDF and a PNG for the insurer and the police.
Design first
The customer asked to work in Figma before code, so that is what I did: a design system with two layers of variables (raw colours, then what they mean in the interface, in light and dark), an 8 px grid, contrast checked against WCAG AA, seven components with variants, and ten screens for desktop and phone, with a dark mode for the busiest ones. After feedback the design split by who uses it: the administrator on a computer, the technician on a phone, out at the robot. The screens in the code follow the Figma file one to one.
What is in it
Seller web app
A Vue 3 PWA with Nuxt UI and Pinia, in English, Dutch, French and German. Companies, robots, defects and replacements with a QR code, roles and rights, view as role, a team and a log.
Seller API
NestJS with code-first GraphQL, subscriptions and DataLoader, on its own MongoDB. Robots keep only the start of their key. Every change to a defect, robot, role or team goes in the log.
Platform simulator
Node 24 and TypeScript, with no packages. It plays the companies' platform with made-up companies, roles, robots and orders, and speaks the whole robot contract: telemetry, queued commands, routes with stops, availability.
Robot app
Flutter. A phone or a PC is the robot: it reports in, takes the commands (stop, return, resume, lock, unlock, beep) and drives its route, and the key comes straight from the web app.
ESP32 node
An RGB LED, a buzzer, a button and a motion sensor. It shows the robot you pick, the button closes a defect, and tilting or shaking the board tilts and shakes the robot. A small bridge talks USB to the board, and a phone can use Bluetooth.
Demo launcher and Docker
A Windows launcher that flashes the board and starts everything with one click, and a docker compose file with its own MongoDB for the teachers.
How it is checked
Everything is checked on the computer of whoever makes the change, before every commit and pull request, with one command that runs type checks, lint, unit tests, the API's end-to-end tests, a build of the web app, the Flutter tests and the Docker config. These counts are the ones in the repository's README:
| Part | Tests |
|---|---|
| Platform simulator | 56, including two whole-day runs with nine simulated robots |
| Seller API | 122 unit and 215 end-to-end, on an in-memory MongoDB |
| Seller web app | 186 unit tests, plus 10 browser tests against the running demo |
| Hardware bridge | 79 |
| Flutter robot app | 314, including nine whole-day runs, also in frost |
What is not tested automatically: the ESP32 firmware (it compiles and runs on a board, but nothing guards it), the real LED, buzzer, button and sensor, and finding and connecting over Bluetooth on a real device, which I tried by hand on Windows. The README says so too.
From a team to me
This started as a team project with a classmate: I had the seller side and the robot, they had the ordering platform. After the feedback moments the teachers decided on 28 October 2026 to split the group work, so everyone carries on alone in their own repository, from the base of their own flows. This repository is a copy from that moment without the other student's ordering platform, which the simulator now plays, so the seller side and the robot keep running against something real. The history before the split is shared, and it is all still in git.
The repository belongs to the Howest class organisation and is private. If you need to see the code, email me.