When the management team at a 40-vendor food truck park and flea market approached us, they had a parking problem that was costing them customers. Every weekend, 300+ vehicles would pour into their lot, and a team of three staff members would manually check paper passes, wave people through, and try to keep track of capacity on a clipboard. The result: 15-minute wait times at peak hours, constant disputes about lot availability, and zero data about how the parking lot was actually being used.
The Problem: Paper Passes Don't Scale
The venue's parking lot holds 220 vehicles. On a busy Saturday, they'd turn over that capacity 2-3 times throughout the day. Staff at the entrance would check paper passes that vendors had distributed to their customers, but the system had fundamental flaws. Passes were easy to forge — a color photocopy was all it took. Staff couldn't tell if a pass had already been used. And when the lot hit capacity, there was no reliable way to know because no one was counting exits. Visitors would drive in, circle the full lot for 10 minutes, and leave frustrated. Management estimated they were losing 15-20% of potential weekend visitors to parking friction alone.
Our Approach: QR-First Architecture
We designed the system around three core components: a QR code generation engine, a scanning and validation layer, and a real-time capacity dashboard. Each component needed to work independently while feeding data into a shared state that would give management complete visibility into lot operations.
The QR generation engine runs on a Python backend using the qrcode library with cryptographic signing. Each QR code encodes a JSON payload containing the vendor ID, customer identifier, timestamp, and a valid-until window, all signed with HMAC-SHA256. This means every QR code is unique, time-limited, and tamper-proof. Vendors generate passes through a simple web interface — they enter the number of passes they need, and the system spits out a PDF sheet of QR codes they can hand or text to their customers.
Scanning and Validation in Under 200ms
At the entrance gate, we deployed tablets running our custom scanning app. When a staff member scans a QR code, the app sends the payload to our validation API, which performs five checks in sequence: signature verification (is this a genuine pass?), expiration check (is it still valid?), single-use verification (has it been scanned before?), vendor status check (is the issuing vendor active today?), and capacity check (is there room in the lot?). The entire validation chain completes in under 200 milliseconds, and the tablet displays a clear green checkmark or red X with the reason for rejection.
We built the API with FastAPI for its async performance characteristics. The single-use tracking uses a Redis set for O(1) lookup times — when a pass is scanned, its hash gets added to the day's set, and any subsequent scan of the same pass hits that set and returns a "previously used" rejection. Redis was the right choice here because the data is ephemeral (we only need the day's scans) and the lookup speed is critical for keeping the entrance queue moving.
The Real-Time Dashboard
The management dashboard was where the project really came together. Built with React and connected via WebSocket, it shows a live view of lot occupancy as a percentage gauge, entry and exit rates graphed over time, per-vendor pass usage (so management knows which vendors are driving the most traffic), and peak hour patterns across the day. We added exit tracking using a simple license plate scan at the exit gate — not for identification, just for counting — which feeds the same WebSocket channel.
Management can view the dashboard from their office, their phone, or a wall-mounted TV in the operations room. When the lot hits 90% capacity, the system automatically triggers a yellow warning on the entrance tablets. At 100%, it switches to red with a "LOT FULL" message and optionally sends an SMS to the management team.
Results: Numbers That Speak
Within the first month of deployment, the results were dramatic. Average entrance processing time dropped from 45 seconds per vehicle to 8 seconds. Parking disputes — which had been a weekly occurrence — dropped to zero. The forged pass problem disappeared entirely since QR codes can't be meaningfully photocopied (the cryptographic signature ensures uniqueness). Most importantly, management finally had data. They discovered that Saturday afternoons between 1-3 PM were their bottleneck, which led them to implement a shuttle service from an overflow lot that recovered an estimated 12% of previously lost visitors.
The per-vendor traffic data turned out to be a powerful management tool as well. Vendors who consistently drove high traffic could be offered premium placement. Vendors with low pass usage could be coached or replaced. The parking system became, somewhat unexpectedly, a vendor performance analytics tool.
Technical Takeaways
A few lessons from this project that apply broadly. First, cryptographic signing at the generation layer eliminates an entire class of fraud problems — don't just generate codes, sign them. Second, Redis is the right tool for high-speed ephemeral lookups; don't reach for a full database when you need sub-millisecond set membership checks. Third, the real value of a system like this often isn't the primary feature (parking validation) but the data layer it creates. The analytics dashboard was a Phase 2 idea that became the most valuable part of the project. Build your data model with future analytics in mind from day one.