Camera reads, reservations, and real-world arrival data do not always agree. The system still needs a fast, human-confirmable path that protects both access and an auditable occupancy record.
Smart Parking System
A smart gate is useless if one weak camera read can trap the entire operation.
- ROLE
- System design · Full-stack engineering · Computer vision
- STATUS
- Private system build
- STACK
- React · Express · FastAPI · YOLOv8 · Computer vision
WHY THIS PRODUCT
NEEDED TO EXIST.
I unified plate detection, reservation lookup, QR-linked receipts, allocation, and operator confirmation into one event flow, with manual verification treated as a first-class state.
THE OPERATING
SEQUENCE.
- 01DETECT
Read the arrival
Camera, reservation, or QR data starts the event.
- 02VALIDATE
Check access
The service compares the incoming signal with reservation and occupancy state.
- 03CONFIRM
Resolve uncertainty
Operators can correct a plate or approve the valid path manually.
- 04LOG
Close the event
The gate result and occupancy change become auditable system state.
DECISIONS THAT
SHAPED THE BUILD.
Multiple arrival signals
A plate, reservation, or QR receipt can begin the same controlled entry flow.
Humans can resolve ambiguity
Weak recognition moves to an operator-confirmable state instead of silently denying access.
Every outcome closes
Entry, rejection, correction, and allocation become explicit events the operator can inspect.
THE SYSTEM.
BEYOND THE INTERFACE.
This case documents architecture, failure handling, and implementation decisions while the product interface and source remain private.
SCOPE OF
RESPONSIBILITY.
I designed the service boundaries across the web interface, Express/FastAPI services, and the YOLOv8-assisted plate pipeline.
The private build documents the operating logic and fallback path. Public interface evidence and a repository are not available, so this case study deliberately avoids invented screenshots.
- Gate operations
- Plate recognition
- Manual fallback
- Occupancy