ParkAlert BLE parking beacon hardware
CASE STUDY / IOT PRODUCT

ParkAlert — BLE parking beacons, idea to shipping.

A startup needed a smart parking solution: BLE beacons that detect when a driver parks and alert the owner in real time. Whiteboard to manufactured retail product, one engineer owning hardware, firmware, apps, and cloud.

CLIENT
ParkAlert
ROLE
Systems architect · Full stack
TIMELINE
< 12 months · shipped
STATUS
● Live

A smart parking beacon has to run for 2+ years on a coin-cell battery, survive outdoor weather, and work with millions of iOS and Android phones — which each handle BLE slightly differently. No agency had the whole stack: PCB, firmware, two native apps, and a backend. The client needed an engineer who could own every layer without handoffs.

The non-negotiables: battery life measured in years (not months), sub-second detection reliability, and over-the-air firmware updates — because recalling hardware in the field after shipping isn't an option.

BLE beaconsCoin-cell 2yriOS + AndroidDFU over BLEPCB designFirmware C

Key decision — Radio

Chose BLE over WiFi and cellular. Power consumption and unit cost both drop by an order of magnitude. WiFi needs ongoing provisioning per location; cellular adds a SIM cost per beacon plus carrier certification per region. BLE with a phone as the bridge was the only approach that fit the product's retail BoM target and 2+ year battery life simultaneously.

Key decision — Firmware updates

Designed DFU (Device Firmware Update) into the beacon from v1. Every beacon in the field can be patched over BLE without physical access. This decision paid for itself within 6 months — a BLE stack bug surfaced in production, and we patched the fleet silently over a weekend instead of issuing a recall.

Trade-offs accepted

BLE is range-limited (meters, not km). Accepted — parking is inherently short-range. The phone-as-bridge pattern means the owner's app has to be installed and nearby; we mitigated with a background scan that runs within iOS/Android battery policies. Backend stayed on Firebase to avoid spending engineering on ops work before product-market fit was proven.

HARDWARE · v2 productionHARDWARE · v2 production
FIELD · deployment
APP · real-time

Full product shipped in under 12 months. iOS and Android apps live in both stores. The beacon platform evolved into a family of 4 IoT products. Manufacturing pipeline established with a Hong Kong supplier. Patent filed (WO2025089955, jointly with ZippLabs) for the underlying access-credential technology.

2+YR
Battery life
coin-cell · outdoor
12MO
Idea → shipping
whiteboard to retail
4
Product lines
shared platform
1
Patent filed
WO2025089955
BLENFCFirmware CPCB designSwiftKotlinReact NativeFirebaseDocker
WEEK 01 — 06 · DISCOVERY
Architecture & PCB

System design, radio selection trade-off, BoM target, initial PCB layout, firmware framework choice, DFU protocol design.

MONTH 02 — 05 · BUILD
Firmware, apps, cloud

Beacon firmware with OTA updates. iOS app (Swift) and Android app (Kotlin) with shared BLE protocol. Firebase backend for beacon registry and alert routing.

MONTH 06 — 09 · PILOT
Field trials

Weatherproofing revisions. Battery-life validation in Dutch climate. iOS/Android BLE quirks tuned per device class. App-store submissions.

MONTH 10 — 12 · SHIP
Manufacturing & retail

Hong Kong supplier validated. First production run shipped. Patent filed. Product family planning for v2 generation started.

"We had an idea and a whiteboard. Sinisa turned it into a shipping product — BLE hardware, firmware, iOS, Android, backend. One engineer who owned the entire stack."
CEO
IoT Startup · Netherlands
Next case studies

Keep reading.

Build something real

Have a system that needs architecting?

No sales pitch, no agency layers. I'll read your situation and reply within 24 hours with whether I'm the right fit.

Start a project See all work