When we open a discussion on data tools (mobile internet of things) for micro mobility everyone is on the same page. Data management has value (… a lot of value), whether it is user functions, battery management tools or GPS tracking. We also know that mobile “things” have a different set of requirements from “fixed” or static assets.
Why are micro mobility e-scooters sidewalk litter?
In reality, data tools operate exactly like a trojan horse. Most micro mobility options are built on proprietary stacks. The IoT layer (telemetry, geofencing, battery management, remote lock/unlock) is tightly coupled to the vehicle hardware and the operator’s cloud. Cities and operators who adopt these systems inherit a vendor’s data model, API, and commercial terms. Switching costs become enormous, especially at scale, so cities license vendors using time limited concessions or operating permits.
Can we build an agnostic (mobile) data transfer layer?
Abstraction: a unified device communication protocol that sits above hardware differences purpose built for kinetic, battery-constrained, public space assets. Data sovereignty: telemetry, trip data, and geofence logic should be owned and portable by the operator or municipality, not held hostage in a vendor SaaS. Interoperability for fleet management: standardized APIs so that operators can mix hardware vendors within a single operational platform.
Neutrality as a service
How does something like this get built? Well, the big vendors do not want to do it because they have a complete stack to sell. That is their value proposition. The core value proposition we are looking at is neutrality as a feature, which runs counter to their focus. Operators want flexibility and negotiating leverage over hardware suppliers. Cities want data access and policy compliance without becoming systems integrators. The hardest problem is the chicken-and-egg scenario. Hardware vendors won’t prioritize your integration until operators demand it.
Remember PC v Mac?
Hardware-first with customizable devices and basic device management is exactly the foundation that the neutral SaaS layer needs to exist. This was the nexus of the PC/Mac debate. A basic PC running some form of windows was a better architecture for general use. You got long term buy-in from gamers, business, office workers and home users.
Making “future ready” choices
Hardware vendors made choices that did not foreclose their options later. That means connectivity module choices support open protocols. Firmware architecture separates device logic from platform logic. Data models at the device level are portable and well-documented. “We’re building the hardware that makes the platform possible, and we’re the only ones doing it intentionally.”
Mechanically you can design for serviceability and modularity in ways that directly support the infrastructure argument. Swappable battery systems, standardized mounting points for connectivity hardware, form factors suited to different urban contexts.
Electronically you can make deliberate choices about the connectivity stack; cellular module selection, onboard compute, sensor architecture. Critically, you can design the electronics so the IoT layer is not married to a specific cloud backend. The strategic synthesis is this: You’re not a hardware company that wants to build software. You’re a company that can ship a physical asset that is natively infrastructure-ready.
Let’s take a simple scenario: A rideshare vendor wants to implement battery swapping technology. One option is that users or techs could login at the battery swapping location with an interface that connects the vehicle -the original battery – the new battery – the user. A combined pain point and profit center of fleet mobility is efficient “juicing.” You make the juicing better, the entire value proposition improves. You create growth, not entropy.
