The idea
A small sensor bar that mounts above a shop doorway, counts people entering and leaving, and pushes the tallies to a dashboard. It uses a time-of-flight ranging sensor rather than a camera, so it never captures an image and has nothing to leak. The dashboard pairs the counts with the till's daily sales export to produce the one number small retailers almost never have: what fraction of the people who walked in actually bought something.
Why build this
Independent shops, cafés, galleries, and gyms make staffing and opening-hours decisions on gut feel. They know Saturday revenue but not whether Saturday was busy-and-converting or quiet-and-desperate. Retail counting systems exist, but they're sold as multi-site enterprise packages at £40–150 per door per month with an installer visit, which prices out the single-location owner entirely.
The hardware side got cheap and boring in the last few years. A VL53L5CX multi-zone ToF sensor is about £15, resolves an 8x8 depth grid out to four metres, and an ESP32-C6 next to it handles Wi-Fi and enough compute to do the counting on-device. Direction of travel falls out of watching which zones break first — no ML model, no training data, no cloud inference bill. The privacy story sells itself: you can tell customers, honestly, that the box physically cannot see them, which matters in jurisdictions where camera-based analytics drags in GDPR consent obligations.
Stack sketch
- Sensor: VL53L5CX ToF module, mounted downward-facing in the door frame; two-zone-band crossing logic for entry/exit direction.
- Firmware: ESP32-C6 with ESP-IDF, counting on-device, buffering to flash when Wi-Fi drops, posting batched counts over MQTT.
- Ingest: Mosquitto behind a small Go service writing to TimescaleDB — counts are pure time-series and hypertables make the hourly rollups trivial.
- Dashboard: SvelteKit, server-rendered, with ECharts for the hour-of-day heatmap. Must be readable on the owner's phone behind the counter.
- Sales join: CSV upload plus direct pulls from the Square and SumUp APIs, which cover most of the independent market.
- Enclosure: 3D-printed, magnet-mounted, USB-C powered from a socket the shop already has.
Scope for v1
In:
- One door, one sensor, one shop.
- Entry/exit counts bucketed to fifteen minutes, with a live "in store now" figure.
- Hour-of-day and day-of-week heatmaps over any date range.
- Manual CSV sales import and a conversion-rate column.
- A calibration mode where the owner walks the doorway ten times and the app confirms it counted ten.
Out: multi-site rollups, dwell time, queue detection, staff-vs-customer distinction, anything resembling identity. Also out: battery power. Requiring a wall socket removes a whole class of support tickets.
Where it could go
The obvious extension is scheduling. Once you have twelve weeks of counts, you can propose staff rotas that match cover to actual demand rather than to habit, and quantify what an extra hour of Sunday opening would have earned. That is the feature owners will pay a real monthly fee for, because it converts the data into a decision.
Second path: the same sensor and pipeline works unchanged for museums reporting visitor numbers to funders, coworking spaces justifying floor space, and libraries filing usage statistics. These buyers need an auditable count and a PDF at the end of the month, not analytics, and they're used to procurement cycles that tolerate a higher price. Third, a benchmark opt-in — anonymised, aggregated footfall by high street and category — becomes genuinely useful once a few hundred doors report, and is the kind of dataset local press quotes for free.
Watch out for
Doorway geometry is where these projects die: wide entrances, double doors, glass that reflects IR, and people entering in tight groups all degrade accuracy, and an owner who catches the count being wrong once stops trusting the dashboard forever. Ship the calibration walk-through as a first-class onboarding step, and show a confidence indicator rather than pretending every count is exact.