Hardware black boxes measure the vehicle. Phone-based SDKs measure the driver. Why software-based telematics took over, where it still struggles, and how the real shortcomings actually get solved.
Ten years ago, “telematics” almost always meant a physical box — an OBD-II dongle plugged under the dash, or a wired unit installed by a technician. Today, most new UBI, BBI, and fleet-safety programs launch on a phone-based SDK instead, with no hardware at all. That shift is now largely complete for consumer and light-commercial programs, and it happened for structural reasons, not fashion. It also created a different set of problems — ones that are easy to gloss over in a sales deck and expensive to discover in production.
Four forces did most of the work.
A mid-range smartphone sold today carries GPS, an accelerometer, a gyroscope, and often a barometer — the same sensor class that used to justify a dedicated hardware SKU. Smartphone ownership among licensed drivers is well past 90% in most markets telematics programs actually target. Once the sensors are already deployed at that scale, building a hardware supply chain to duplicate them is a cost decision, not a capability decision.
A simple OBD-II dongle typically runs somewhere in the $20–$60 range per unit at volume; a hardwired, tamper-resistant fleet unit is commonly $100–$300+ once you include installation labor. Either way, someone has to manufacture it, ship it, warehouse it, install it, and eventually replace it when it’s lost, damaged, or the vehicle is sold. An SDK ships inside an app a driver downloads in minutes. That difference compounds fast once a program is trying to onboard thousands of drivers a month instead of dozens.
Most hardware telematics still leans on the OBD-II port for vehicle data. That port was standardized around emissions diagnostics for internal combustion engines, and it's a shakier foundation every year: many EV platforms don’t expose the same PIDs as ICE vehicles, and several manufacturers are moving toward proprietary or restricted diagnostic access rather than an open port. A hardware program built entirely around OBD-II is building on ground that's actively shifting under it. A phone-based SDK never depended on that port to begin with.
A unit bolted to the OBD port or wired into the vehicle can measure the vehicle — speed, hard braking, rapid acceleration. It cannot see whether the driver is holding a phone. Distracted driving is routinely cited by NHTSA as a factor in several thousand US road deaths a year, on the order of several deaths a day — and a vehicle-mounted black box has zero visibility into it. That single blind spot is arguably the biggest reason insurers and fleets moved toward phone-based detection: the device most likely to cause the crash is also the only device that can measure the distraction.
Hardware measures the vehicle. Software measures the driver. For most modern programs, the driver is the harder and more valuable thing to measure.
None of this makes phone-based telematics easy. It trades hardware problems for a different, harder set of software problems — and a program that hasn’t been pressure-tested against them tends to look great in a pilot and fall apart at scale.
iOS and Android both treat background location and sensor access as battery liabilities, not features, and both have gotten more aggressive about it with every major release. Handled naively, a backgrounded app's GPS callbacks can get batched minutes apart instead of arriving in real time, which is close to useless for trip detection. This isn’t a bug an SDK vendor can file a ticket about — it's the platform working as designed, and every phone-based telematics product has to build around it.
Most SDKs get built and demoed on flagship test devices. Most fleets — especially in the markets where UBI and BBI programs are actually growing — run on budget OEM Android hardware, where aggressive third-party process killers and custom battery-management layers on top of stock Android will silently kill a background service within minutes if it isn’t specifically hardened against them. An SDK that works perfectly in the lab and quietly stops detecting trips in the field isn’t a rare failure mode; it's close to the default outcome if this isn’t tested for explicitly.
Is it mounted on the dash, in a pocket, in a cupholder, or being held? Each position changes what the raw accelerometer and gyroscope data look like, and getting it wrong produces both false positives (a phone bouncing in a cupholder over a pothole reads like a hard brake) and false negatives (a mounted phone under-reports genuine handling). Hardware doesn’t have this problem because it's fixed in one known position by design.
A wired unit is unambiguously attached to one vehicle. A phone is unambiguously attached to one person — who might be a passenger, not the driver. Attribution has to be inferred from secondary signals (motion pattern, historical behavior, sometimes Bluetooth pairing to the vehicle), and it's never as certain as hardware's simple guarantee.
This one isn’t technical, and it's arguably the hardest problem on this list. A driver can revoke a location permission or delete an app in seconds. A hardwired fleet unit generally can’t be casually disabled by the person being measured. Any consumer-facing SDK program has to solve for engagement and compliance, not just detection accuracy.
None of the problems above are solved by wishing them away, and none of them are solved once and forgotten — they get solved by specific, ongoing engineering choices, tested against the conditions that actually break them.
The honest version of this list is that none of it is a one-time fix. Device fragmentation gets worse as new budget OEM models ship every year, not better. It has to be tested continuously against real hardware, not validated once and assumed to hold.
This isn’t a case for software everywhere. Commercial fleet programs that need vehicle-level diagnostics — odometer readings, fuel data, engine fault codes, asset location independent of whoever happens to be driving — are still better served by hardware that's wired into the vehicle itself, not a phone that might be left at home. Heavy-duty and asset-tracking use cases were never really the software-vs-hardware argument in the first place.
For consumer and light-commercial UBI, BBI, and driver-behavior programs, though, the calculus has moved decisively toward software. If you’re evaluating a vendor on either side of that line, the useful question isn’t “hardware or software” in the abstract — it's whether they can show you what happens to their detection on a budget Android phone after the OS kills the app in the background, because that's where most phone-based programs actually fail.