There is a strong idea inside RoadDex. There is also a dangerous one sitting right next to it.
The strong idea is simple: Pakistan has a stolen-vehicle problem, citizens already circulate stolen-car alerts in WhatsApp groups, and police resources are not infinite. If thousands of phones on the road can passively scan number plates and match them against a verified stolen-vehicle list, then a stolen car can be seen faster than any single victim, constable, or WhatsApp group could manage.
The dangerous idea is also simple: a country that normalizes passive number plate scanning without strict legal, technical, and civic boundaries can quietly build a distributed surveillance layer without admitting it has built one.
That is why RoadDex APB should not be judged as “good” or “bad” in one sentence. It should be judged by design. A citizen-tech recovery system can be useful. A citizen-powered location database can be abused. Both statements are true.
Pakistan already has official number plate recognition infrastructure in parts of Punjab. PITB describes AI-based Automated Number Plate Recognition as part of the Punjab Safe City initiative, designed to capture and register licence plate information for monitoring and identifying vehicles involved in criminal activity. Punjab Police also has an Anti Vehicle Lifting System that centralizes stolen-vehicle data across Punjab’s 36 districts for tracking and management. So the question is not whether ANPR exists. It already does. The real question is whether a privately built, citizen-powered version can be made safer than the informal WhatsApp chaos it wants to replace.
The answer is: yes, but only if RoadDex refuses to become a public car-location search engine.
A stolen vehicle alert should not mean “anyone can see where this car was last spotted.” That is wrong. A user reward system should not mean “citizens are encouraged to chase, confront, or intercept cars.” That is wrong. A private app should not silently build a historical map of every innocent car scanned on Pakistani roads. That is also wrong.
The only defensible version of RoadDex APB is a narrow, verified, police-routed stolen-vehicle alert system where the scanner does not know whose car was detected, the car owner does not know who spotted it, and the public never gets access to raw location trails.
The founder’s own framing shows he understands the unease. The supplied LinkedIn post says the APB idea would allow a verified vehicle owner to register a car, issue an APB after theft, allow passive RoadDex scanners to detect the plate, log the location, and route sightings to police. It also says the person spotting the car stays anonymous to everyone except police, and that there would be no ads or data selling. That is the right starting instinct. But intent is not a safeguard. Architecture is.
The first safeguard must be ownership verification. A person should not be able to enter any plate and receive sightings. They must prove ownership through registration documents, CNIC-linked verification where lawful, insurance or excise record matching where available, and a police FIR or e-report reference before an APB goes live. Even then, the app should not expose live coordinates to the vehicle owner. It should only confirm that the case has been forwarded through the proper channel.
The second safeguard must be a police-controlled handoff. The founder says the police portal matters because he does not want this to become a vigilante tool. That concern is correct. A stolen-vehicle detection system without police routing can encourage civilians to chase suspects, misidentify vehicles, or create public harassment. The APB should generate a police-facing alert, not a mob-facing notification.
The third safeguard must be data minimization. RoadDex should not store every plate scanned by every user. It should check scans against a hashed, active APB list and discard non-matches immediately. Non-stolen vehicles should not become entries in a private mobility database. No “last seen” history for normal cars. No searchable plate history. No exportable movement map. No casual dashboard. No marketing data. No insurance resale. No analytics product. Nothing.
The fourth safeguard must be delayed and filtered notification. Real-time location should not go to private individuals. Even police alerts should include confidence scoring, duplicate detection, location accuracy, timestamp, device trust score, and image evidence where legally permissible. False positives in number plate recognition are not theoretical; they are expected in real-world OCR environments because plates can be dirty, stylized, partially blocked, cloned, tampered with, or misread.
The fifth safeguard must be an anti-stalking design. This is where the unease in the comments is valid. A passive road user has not consented to being logged by a random app. A person escaping domestic violence, a journalist, a political worker, a business rival, or a citizen in a sensitive situation should not be exposed through a consumer app dressed as civic utility. Pakistan currently does not have a fully enacted, comprehensive personal data protection law equivalent to GDPR-style regimes, while PECA and proposed data protection frameworks remain the relevant privacy/legal backdrop. That gap makes product restraint even more important, not less.
The sixth safeguard must be auditability. Every APB creation, police access, data retrieval, reward claim, and admin override should be logged. Abuse should be traceable. A police officer, app employee, or claimant should not be able to quietly check someone’s plate history. If there is no audit trail, there is no trust.
The seventh safeguard must be a strict reward model. Rewarding users for sightings is clever, but it can also distort behavior. People may drive into risky areas, chase cars, or try to game the system. The reward should be paid only for passive detection, never for pursuit. The app should explicitly say: do not follow, stop, confront, photograph people, or intervene. Let the system detect. Let police act.
This is where the APB concept becomes genuinely interesting. It is not a replacement for police. It is not a vigilante network. It is not a surveillance toy. It is a civic sensor layer with a single permitted purpose: help recover verified stolen vehicles through lawful channels.
Pakistan’s current stolen-vehicle reporting ecosystem is fragmented. Victims post on WhatsApp, Facebook, X, neighbourhood groups, car-market groups, and private contacts. That creates noise. It also creates risk. A forwarded stolen-car post may be outdated, fake, malicious, or missing context. RoadDex can improve this only if it adds verification, expiry, police handoff, and controlled disclosure.
The expiry system is essential. Every APB should automatically expire unless renewed by official case status. A recovered car should be removed immediately. A disputed ownership claim should suspend the APB. A fake claim should permanently ban the claimant and generate a legal record. This cannot be casual.
Technically, the APB list should be small, active, encrypted, and privacy-preserving. The app can compare detected plates against active alerts locally or through a secure server process that does not retain non-matches. Heatmaps may be fine for a user’s own driving coverage, but they should never become public plate-location heatmaps. Gamification is acceptable for generic scanning XP. It is not acceptable for stalking-adjacent plate hunting.
The supplied graphic does a good job explaining the intended workflow: register the vehicle, activate APB, scan passively, match and log, route to police, reward the spotter. As a concept graphic, it is clear. As a product roadmap, it still needs a visible privacy layer. The next version should show “non-matches deleted,” “owner cannot view live location,” “police-only case access,” “scanner remains anonymous,” and “no chasing allowed.” Without those labels, critics will read the visual as surveillance. They will not be wrong to worry.
My view is straightforward: RoadDex APB is worth exploring, but not as a public beta with live stolen-vehicle tracking. It should begin as a closed pilot with one police unit, one city, strict legal review, limited APB volume, independent privacy consultation, manual verification, and public transparency reporting.
Build the boring governance before building the exciting dashboard.
That is the difference between citizen-tech and citizen-surveillance.
A useful version of RoadDex APB would say: “We helped police recover a stolen car.” A dangerous version would say: “Anyone can find where a plate was last seen.” One is civic infrastructure. The other is a privacy breach waiting for its first scandal.
Pakistan does need better stolen-vehicle recovery systems. It does need smarter law enforcement technology. It does need innovation from builders who understand local realities. But every founder building in public safety must accept one hard rule: when your product touches location, identity, vehicles, police, and rewards, your privacy architecture is not a feature. It is the product.
RoadDex should proceed.
But it should proceed with locks before speed.
